Anthropic Managed Agents 深度研究：解耦大脑与双手的架构哲学
原文链接：Scaling Managed Agents: Decoupling the brain from the hands 研究时间：2026-04-14 研究方法：多轮迭代搜索 + 交叉验证 + 结构化综合 前言：从"程序即未设想之物"说起 Anthropic 在 2026 年 4 月发布的 Managed Agents 服务，解决了一个经典的计算机科学问题：如何为"尚未设想的程序"设计系统。 这个问题的答案，早在几十年前操作系统设计时就已经给出——通过虚拟化硬件为通用抽象（进程、文件），使得 read() 系统调用既能访问 1970 年代的磁盘组，也能访问现代 SSD。抽象层保持稳定，底层实现自由演进。 Managed Agents 做了同样的事情：将 Agent 组件虚拟化为三个核心抽象——Session、Harness、Sandbox，使得未来的 Harness 实现、Sandbox 技术或上下文工程策略都可以独立演进，而接口保持稳定。 本文是对这篇工程博客及相关技术的深度研究报告。 一、核心架构：三层解耦设计 1.1 ...
Claude Code 源码深度解析：五层架构与核心设计模式
全景导图 %%{init: {'theme':'base', 'themeVariables': {'primaryColor':'#e3f2fd','primaryTextColor':'#1565c0','primaryBorderColor':'#1976d2','lineColor':'#42a5f5','secondaryColor':'#fff3e0','tertiaryColor':'#f3e5f5','fontSize':'14px'}}}%% flowchart TD A[Entrypoints 入口层] --> B[Runtime 运行时层] ...
Compound Engineering：当 AI 工程从"模型调优"走向"系统组合"
2024 年之前，AI 工程的核心问题是"怎么让模型更好"。2024 年之后，核心问题变成了"怎么让多个组件协作得更好"。这个转变的名字叫 Compound AI Systems，而围绕它的工程学科叫 Compound Engineering。本文从"为什么单体模型不够"出发，系统梳理复合 AI 系统的架构模式、工程实践和与其他 Engineering 概念的关系。 一个类比秒懂 Compound Engineering 在讲技术之前，先用一个类比。 想象你要建一座现代化医院： 单体模型思维就像雇一个全科天才医生，让他一个人看所有病人——内科、外科、眼科、牙科全包。他确实很聪明，但一个人的精力和专业深度终究有限。 Compound AI Systems 思维就像建一个多科室协作的医院系统：有分诊台（路由器）、各科室的专科医生（专用模型）、病历档案室（检索器）、化验室（外部工具）、会诊机制（多智能体协作）。每个组件做自己最擅长的事，通过协作协议连接在一起。 Compound Engineering 就是设计和运营这...
驾驭工程全景：从 Prompt Engineering 到 Context Engineering 再到 Harness Engineering 的三级跃迁
2020 年我们学会了跟模型说话（Prompt Engineering），2025 年我们学会了给模型喂信息（Context Engineering），2026 年我们学会了给模型搭脚手架（Harness Engineering）。这三个 Engineering 不是并列关系，而是严格的超集关系：PE ⊂ CE ⊂ HE。本文从"为什么上一个不够"的视角，系统梳理这条演进路径上的每一次范式跃迁。 一个类比秒懂三级跃迁 在讲技术之前，先用一个所有人都能理解的类比。 想象你要指挥一个完全失忆的天才厨师做一桌满汉全席： Prompt Engineering 就是学会怎么跟厨师下达指令。你发现说"做道好吃的"不行，得说"用中火煎三分钟，翻面后加酱油 15 毫升"。这是措辞的艺术。 Context Engineering 就是学会怎么给厨师备料。光会下指令不够——厨师面前得摆好食材、调料、菜谱、食客的过敏信息。你要设计一个动态备料系统，让厨师在需要的时候拿到需要的东西。 Harness Engineering 就是学会怎么...
harness的一种实践方法
当我们让 AI Agent 实现一个功能，它思考了一下，开始写代码。200 行写完，运行 lint 直接失败。我们发现类型定义文件 import 了配置包，但是违反了我们期望的架构分层约束，因为 Agent 不知道这个规则，当然我们也没告诉它。 于是它开始修复：移动代码、调整依赖、重新组织。再跑 lint——又一个新问题。循环三次后，上下文窗口被错误日志和 diff 塞满，Agent 开始"忘记"最初的任务目标。 这不是 Agent 不够聪明。这是 Agent 看不见。 你可能也遇到过类似的事情：同一个项目，昨天的 AI 还记得你们的架构约定，今天开个新会话又全忘了。每次协作都要重新解释一遍背景、分层规则、命名规范。AI 生成的代码能跑，但完全不符合团队规范，code review 时才发现一堆问题。让它修 bug，结果引入了新 bug——没有自动验证，全靠人肉检查。 如果换成一个新入职的工程师，他可能也不熟悉代码库，但至少会问一句：“这个文件应该放在哪个目录？”"这样 import 可以吗？"他在行动前寻求验证。AI Agent 不会。它...
长时任务的 Harness 设计艺术
原文：Harness design for long-running application development 作者：Prithvi Rajasekaran，Anthropic Labs 团队成员 发布日期：2026 年 3 月 24 日 Harness 设计是前沿 Agent 编程性能的关键所在。本文介绍我们如何在前端设计和长时自主软件工程两个方向上，将 Claude 的表现大幅推进到基线之上。 过去几个月，我一直在研究两个相互关联的问题：如何让 Claude 生成高质量的前端设计，以及如何让它在无人干预的情况下构建完整的应用程序。这项工作源于我们早期在前端设计 Skill 和长时编程 Agent Harness 上的探索——通过提示词工程和 Harness 设计，我和同事们将 Claude 的表现大幅提升到了基线之上，但两个方向最终都遇到了瓶颈。 为了突破这一瓶颈，我寻找了在两个截然不同领域都能奏效的新型 AI 工程方法——一个领域以主观审美为核心，另一个以可验证的正确性和可用性为核心。受生成对抗网络（GAN）的启发，我设计了一种包含生成器和评估器 Agent 的...
OpenSpec 实战指南：从工作流到落地
为什么需要 OpenSpec 在 AI 编程时代，真正的难点往往不是“AI 会不会写代码”，而是“AI 能不能稳定写出你真正想要的代码”。问题往往不在模型能力，而在于需求、边界、约束和验收标准没有被稳定地表达出来。当意图没有沉淀为可复用的工程事实，AI 就只能在模糊上下文里“猜”。 OpenSpec 解决的正是这个问题。它的核心思想可以概括成一句话：先对齐规范，再生成代码（align before code）。与其把 AI 当成一个只看提示词的即时执行器，不如把它放进一套可追溯、可迭代、可沉淀的规范工作流里。 OpenSpec 既不是重量级流程平台，也不是传统瀑布式文档系统。从实践上看，它更像一套轻量的仓库内协议： 用 specs/ 保存系统当前已经成立的事实； 用 changes/ 保存本次准备引入的未来变化； 用 proposal、spec、design、tasks 把“为什么改、改成什么、怎么实现”拆开表达； 用 sync 和 archive 把一次变更逐步沉淀为下一次变更的上下文。 它的设计哲学，基本可以概括为四点： Fluid not rigid：规范是活文档，不...
子 Agent 的本质：上下文隔离与专门化
"子 Agent"这个词在多 Agent 系统的讨论中频繁出现，却鲜有人把它说清楚。它是一个能力弱化的 Agent，类似一个 Agent 化的工具？还是一个拥有更小上下文的原始 Agent，像从主 Agent fork 出来的进程？还是一个在指挥体系里听从领导 Agent、但拥有更强资源和能力的 Agent？ 这三种直觉都不完全准确。本文从 Anthropic、LangChain、Claude Code 等权威来源出发，厘清子 Agent 的真实本质，并探讨一个更深层的问题："子 Agent"究竟是能力描述，还是关系描述？ 三种直觉，三种误解 在深入定义之前，先把三种常见直觉逐一检验。 误解一：子 Agent 是能力弱化的 Agent 这种直觉来自于"子"字的字面含义——子集、子系统、子进程，往往意味着更小、更弱。但 LangChain 官方文档明确指出： “An interesting aspect of this approach is that sub-agents may have the exact sam...
Coding Agent 架构祛魅：从 Claude Code 到 OpenCode 的真实实现
围绕 Coding Agent 的讨论，常见两种极端：将其神化为自主智能体，或将其贬为"不过是提示词工程"。两种判断都失之简单。本文从真实的架构出发，拆解 Claude Code、OpenCode 等工具的实现模式，厘清各自的设计取舍，以及那些被反复误解的核心问题。 一个循环统治一切 先说结论：所有 Coding Agent 的核心，都是一个 while(tool_use) 循环。 通过对 Claude Code 实际 API 流量的追踪分析，其核心逻辑可以用伪代码描述如下： 12345678while True: response = llm.call(context) if response.has_tool_call(): result = execute_tool(response.tool_call) context.append(result) else: # 没有工具调用 = 任务完成，等待用户输入 break 没有复杂的状态机，没有多 Agent 协调框架，没有专门的&...
git worktree 术语起源解析
引言 在使用 Git 的过程中，你可能会遇到 git worktree 这个命令。这个名字看起来有些特别——为什么叫 “worktree” 而不是 “workspace” 或其他更常见的词？这背后其实有一段有趣的技术历史。 核心答案 worktree 是 working tree（工作树）的缩写，来源于 Git 内部的核心概念。 这不是一个凭空创造的新词，而是直接引用了 Git 自诞生以来就存在的基础术语。 Git 的三大核心区域 要理解 worktree 的命名，首先需要了解 Git 的三大核心区域： 区域 英文名称 别名 作用 仓库 Repository - 存储所有版本历史和元数据（.git 目录） 工作树 Working Tree Working Directory 用户实际编辑文件的目录 暂存区 Index Staging Area 准备提交的文件快照 Working Tree 的含义 Working Tree（工作树）指的是检出（checkout）到文件系统中的文件集合。它是你能够直接看到、编辑的目录和文件。 12345my-project...
