Skip to content

15-agent-philosophy-and-anthropic-design.md

Latest commit

 

History

History
221 lines (145 loc) · 12.7 KB

15-agent-philosophy-and-anthropic-design.md

File metadata and controls

221 lines (145 loc) · 12.7 KB

15. Agent 设计理念研究：从 Claude Code 看 Anthropic 的方法论

所属层级：第四层「Anthropic 在做什么」

建议前读：07. QueryEngine 与上下文

建议后读：17. 系统提示词与模型决策、19. 上下文压缩与历史治理、20. Coordinator、Swarm 与 Teammate 协作

这篇讲什么

这一章不是产品使用说明，而是基于当前源码快照做的一次研究型归纳：Anthropic 在 Claude Code 里，似乎把什么样的 agent 当作“好的 agent”，又是如何把这种理念落实到 prompt、权限、验证、隔离和协作机制中的。

阅读提醒

这篇的写法刻意分成三层：

  • 源码事实：能从代码、注释、prompt 或类型直接确认。
  • 设计解释：对这些事实做设计层归纳。
  • 文档判断：说明这对理解 Anthropic 的 agent 方法论意味着什么。

其中 设计解释 和 文档判断 都带有解释性，不应被当作 Anthropic 官方声明。

这篇与其他研究热点的关系

这一章负责回答“Anthropic 整体上似乎怎样定义好 agent”。如果你还想继续追具体热点，建议这样接着读：

证据池

本章只基于以下文件归纳，不额外延展到更外围的不可闭环模块：

Mermaid 图：Anthropic Agent 工作法图

flowchart LR
    A["Explore\n只读探索"] --> B["Plan\n只读规划"]
    B --> C["Implement\n受权限约束地执行"]
    C --> D["Verify\n独立对抗验证"]
    D --> E["Report\n简洁汇报"]
    D -.失败.-> C
Loading

Mermaid 图：理念与机制映射图

flowchart TD
    A["角色分工"] --> A1["general-purpose / Explore / Plan / verification"]
    B["权限阶段"] --> B1["PermissionMode / EnterPlanMode / ExitPlanMode"]
    C["独立验证"] --> C1["verification agent / verdict contract"]
    D["上下文治理"] --> D1["fork / omitClaudeMd / QueryEngine state"]
    E["安全内生化"] --> E1["permissionSetup / dangerous rules / read-only agents"]
    F["团队协作语义"] --> F1["name / team_name / leader approval / tasks"]
Loading

理念一：Agent 不是“万能体”，而是被分工的专业角色

源码事实

  • 内建 agent 明确分成 general-purpose、Explore、Plan、verification 等角色。
  • general-purpose 强调多步研究、广泛搜索和完成任务，但要求报告简洁、不要过度工程。
  • Explore 是严格只读代理，禁止创建、修改、删除文件，也禁止任何改变系统状态的命令。
  • Plan 同样是只读代理，职责是探索代码库并产出实现计划。
  • verification 的职责被明写为“不是确认实现能工作，而是尝试把它搞坏”。

设计解释

Anthropic 在这里明显没有把 agent 设计成“单一大模型 + 全部工具 = 万能执行器”，而是更像给不同 agent 分配不同工种。探索、规划、实现、验证不是同一角色的不同心情，而是被制度化成不同 prompt 和工具约束的工作身份。

文档判断

这更接近“软件团队分工”的设计，而不是“一个超级代理包办全部环节”的设计。Anthropic 似乎认为，agent 的可靠性来自角色边界，而不只是模型本身更聪明。

理念二：Plan 不是思考姿态，而是正式的权限阶段

源码事实

  • plan 被定义为 PermissionMode 的一员，而不是普通 UI 标记。
  • EnterPlanModeTool 会在进入时切换到 plan 权限模式，并明确要求只读探索和方案设计。
  • ExitPlanModeV2Tool 会验证当前是否真在 plan 模式下；对普通会话会要求用户确认退出；对 teammate 流程会走审批路径。
  • ExitPlanModeV2Tool 现在会写入 plan 文件，因此它已经不是纯会话提示，而是带持久化语义的正式步骤。

设计解释

Anthropic 在这里把“先计划再动手”从软性流程变成了硬性状态机的一部分。计划阶段不只是鼓励 agent 多想想，而是通过权限系统禁止它直接进入写文件和执行实现的路径。

文档判断

这反映出一个很鲜明的设计理念：好的 agent 不只是会规划，而是知道自己何时应该被限制在规划阶段。也就是说，计划能力在这里不是认知增强，而是安全与协作机制的一部分。

理念三：验证必须独立于实现，甚至要带对抗性

源码事实

  • verificationAgent 的 system prompt 明确说“你的工作不是确认实现有效，而是试图破坏它”。
  • 默认 prompt 中还强调：当发生非平凡实现时，必须有独立、对抗性的验证；实现者自己的检查不算数。
  • verificationAgent 被要求运行命令、保存证据、给出 VERDICT: PASS/FAIL/PARTIAL，而不是写模糊总结。
  • 它被严格禁止修改项目目录，只允许在临时目录写临时验证脚本。

设计解释

Anthropic 显然把“实现者自证成功”视为不可靠行为，并通过专门 verifier 来打断这种自我确认闭环。这种思路非常像组织设计中的职责分离：实现和验收不能是同一视角。

文档判断

这说明 Anthropic 追求的不是“agent 更有信心”，而是“系统更不容易被错误乐观欺骗”。在 agent 方法论上，这是一种明显偏向审计与对抗验证的取向。

理念四：上下文窗口是稀缺资源，必须被治理

源码事实

  • QueryEngine 明确保留 mutableMessages、discoveredSkillNames、loadedNestedMemoryPaths 等会话级状态。
  • prompts.ts 里明确建议在研究和多步任务中使用 AgentTool 或 fork，以免原始输出把主上下文塞满。
  • prompt 中还明确强调：如果已经把研究委托给 subagent，不要自己重复做同样搜索。
  • loadAgentsDir.ts 中存在 omitClaudeMd，注释直接写明 Read-only agent 不需要把完整 CLAUDE.md 注入上下文，以节省 token。
  • systemPrompt.ts 会根据模式选择“默认 prompt 被替换”还是“默认 prompt 上追加 agent 指令”。

设计解释

Anthropic 并没有把上下文当成一个无代价的共享黑板，而是把它当成需要精细预算和裁剪的资源。agent 被设计成既要做事，也要主动避免污染主上下文。

文档判断

这反映出一种很实用的 agent 观：好的 agent 不只是完成任务，还要管理自己的上下文成本。把探索、验证、fork、memory 范围控制都纳入设计，说明 Anthropic 很重视“长会话下的上下文卫生”。

理念五：安全不是外部护栏，而是 agent 工作流本体

源码事实

  • 默认 system prompt 直接把 permission mode 解释为工具执行的一部分。
  • permissionSetup.ts 会识别危险 Bash 规则、危险 PowerShell 规则，以及自动批准子代理的危险规则。
  • 文件系统权限模块对敏感路径、可疑路径、内部路径、agent memory、tasks 目录都有显式判断。
  • Explore 和 Plan 代理不只是“建议只读”，而是明确禁止写操作、重定向和状态改变命令。

设计解释

Anthropic 在这里并不是先设计一个强大的 agent，再在外围补一层安全确认；相反，安全约束本身就是 agent 的工作定义。一个 agent 是否能写、何时能写、写什么算危险，都是角色设计和权限设计共同决定的。

文档判断

这让 Claude Code 更像“受监督的半自动工程系统”，而不是“给模型 root 权限再靠提示词劝它克制”。这也是它和很多更自由的 agent 实验形态的重要差别。

理念六：Anthropic 想要的是“同事型 agent”，不是“神谕型 agent”

源码事实

  • 默认 prompt 反复强调：先读代码再改、不要做超出需求的改进、不要为假想需求抽象、不要过度写注释。
  • general-purpose agent 要求把结果简洁汇报给调用者，由调用者再转达给用户。
  • AgentTool 支持 name、team_name、mode、后台运行、foreground/background 切换。
  • ExitPlanModeV2Tool 和 teammate/leader 逻辑表明，agent 可以处在一个“需要别人批准”的团队关系里。

设计解释

这里的 agent 更像团队成员：有角色、有上下级关系、有审批、有交接、有汇报格式。它被鼓励表现出判断力，但不能越过工作边界。

文档判断

Anthropic 似乎追求的不是“模型像神一样无所不能”，而是“模型像专业同事一样，在制度中可靠工作”。这会让系统看起来不那么自由，但更接近企业和工程组织可接受的自动化形态。

理念七：Agent 的好坏，最终体现在工作法而不是人格设定

源码事实

  • prompt 文本大量是方法约束，而不是性格修饰。
  • 核心要求集中在：读代码、别乱猜、别重复劳动、先计划、独立验证、真实汇报、避免过度抽象。
  • 即使在 system prompt 中提到 assertiveness，也仍然服务于任务完成、纠错和真实报告，而不是塑造“有趣人格”。

设计解释

Anthropic 在这里似乎把 agent 设计理解成“工作法编排”问题，而不是“人格调参”问题。系统的重点不在于让 agent 更像某种角色扮演人物，而在于让它在工程任务中采用可预测的方法。

文档判断

这也是 Claude Code 与很多强调角色拟态、口吻风格的 agent 系统的不同点。Anthropic 在这份快照里更在乎 agent 的流程纪律，而不是角色表演。

反例与边界

为了避免过度解读，下面这些点需要明确：

  • 我们能确认的是源码中的 prompt、类型、注释和机制设计，不能确认 Anthropic 内部是否用同样语言表述这些理念。
  • 某些机制受 feature flag 控制，因此“设计上存在”不等于“所有版本默认开启”。
  • 这是一份快照，不足以证明 Anthropic 当前线上产品仍完全采用同样设计。

这篇的工作结论

如果只用一句话总结：从这份快照看，Anthropic 设计的不是“一个拥有很多工具的模型”，而是一套有角色分工、上下文治理、正式权限阶段、独立验证和团队协作语义的工程 agent 体系。

换句话说，Claude Code 里的 agent 设计理念更接近：

  • 工程组织学
  • 安全控制学
  • 上下文资源治理

而不只是“把更多工具塞给模型”。

延伸阅读