421 份系统提示词拆解：给自建 Agent 的四层提示词重构

Agent 基座交付后，短板在提示词

这周我的知识库项目 Cognik 交付了 v1.3 Agent 基座：自建 ReAct Loop（推理 - 行动循环，模型先想再做、循环往复）、9 个工具、SubAgent 异步派发（子代理：主 agent 派出去干活的下级 agent）、五级上下文压缩、记忆提取。期间还弃用了 Eino 框架 —— 它不支持真异步工具，SubAgent 派发做不了，于是参考 Claude Code 自建基座。

基座能跑之后，问题暴露了：提示词太薄。

主 Agent 提示词只有 30 多行英文：身份 + 几条原则 + 检索优先级。SubAgent 指令是单行。13 个工具的描述大多也只有一行。

功能是发动机，提示词是操作手册。手册写得含糊，执行者就自由发挥：乱调工具、编造结果、该问的不问、不该做的直接做。

于是这天我干了一件事：把业界成熟 agent 的系统提示词拆开看。

拆 421 份提示词：两条流

克隆了公开收集的系统提示词库，21 家厂商、421 份文件，逐份分析。按同构性分两条流：

• 流 A：Codex / Cursor / Devin / Amp / Zed 等通用工具型 agent
• 流 B：Claude Code 族 —— 与我的自建基座最同构（ReActAgent + 子 agent + 工具目录），参照价值最直接

每条流提炼出 Top 技法：

对照出六个差距：工具调用纪律缺失、SubAgent 指令过简、工具描述密度不足、诚实 / 反幻觉规则未显式化、破坏性操作护栏缺失、输出规范模糊。

四层改法：从主提示词到工具描述

提示词不是一个文件，是四层结构。每层单独改：

flowchart TB
    L1["层 1 主 Agent 提示词<br/>重排章节：诚实契约置顶第二<br/>补工具纪律、输出规范"]
    L2["层 2 SubAgent 指令<br/>单行 → 角色 + 范围 + 何时委派 + 输出约定"]
    L3["层 3 工具描述<br/>13 个工具单行 → 五要素格式"]
    L4["层 4 内部 forked agent<br/>压缩器/记忆提取等<br/>统一输出约束 + 诚实条款"]
    L1 --> L2 --> L3 --> L4

层 1 的关键是章节顺序。Claude Code 把诚实契约放在第二位，排在所有行为规则之前 —— 顺序即优先级，模型对开头的指令执行力最强。

层 3 最出效果。工具描述从单行升级为五要素，以知识库检索工具为例：

Search the knowledge base for relevant content.
- Use search for keyword queries; use get when you have an exact doc ID.
- Use when answering domain questions before falling back to web_search.
- Do NOT use for ticket status queries — use the ticket tool instead.

「何时 不 调用」比」何时调用」更值钱：模型误调工具，多数是没人告诉它边界在哪。

层 4 常被忽略。压缩器、记忆提取这类内部 agent 也要约束：不编造记忆、不把模型生成的伪用户消息当真实输入。

落地：两阶段与验收

分两阶段交付，先文档后代码：

1. Phase A：设计文档 docs/design/PROMPT.md —— 参考分析、差距表、每条设计决策标注来源文件
2. Phase B：四层源码落地，验收标准是编译通过、集成测试不回归、人工对话验证纪律生效

三条可复用的经验：

• 调研先于选型：Eino 的异步缺陷如果选型期就查到，就不用返工。看框架，重点看它不支持什么
• 提示词密度是工程问题：不是文笔，是把」纪律、边界、护栏」逐条写显式
• 参照系选同构的：421 份里真正有用的是 Claude Code 族那部分，因为架构相同，技法可平移

这周其他进展一句话带过：知识库项目一周三版（v1.1 存储解离、v1.2 联调、v1.3 基座）、AutoSync 定了六条产品化修复清单、推免材料启动。

参考资料

• system-prompts-and-models-of-ai-tools：Cursor / Claude Code / Devin 等 20+ 工具的系统提示词收集
• Cognik：本文的自建 Agent 知识库项目
• Eino：字节开源的 Go LLM 应用框架
• Claude Code 文档