给野马套上缰绳：Agent Harness 工程实践 ——从范式理论到钉钉AI招聘的真实落地

业内一个常被引用的类比是：模型是 CPU，Harness 是操作系统——CPU 再快，OS 拉胯也白搭。这就是为什么 Anthropic 的 Claude Code 能撑起它商业化的重要一极：本质不是更强的模型，而是更好的 Harness。

一张图看懂 Agent + Harness 五层运行时

把 Prompt、Context、Harness 三代范式落到系统层面，本质是一张"围绕 Model 展开的运行时全景图"。你可以把下面这张图当作后文所有铁律、模式、标杆案例的物理地图——每一条最佳实践，都对应图中的某一个位置。

图中两条线索值得反复回看：

• 纵向五层：从 User Interaction 到 MCP，是一次用户请求在系统里流过的完整路径。Workspace 以一个横跨能力层与执行层的容器出现，它不是"某一层"，而是所有层次共享的状态基座。
• 左侧 HARNESS 竖栏：Context Engineering / Architecture Constraints / Feedback Loop / Entropy Management，是把"野马"变成"可生产系统"的四根护栏，垂直穿透每一层。真正成熟的团队，不是在某一层做得特别花哨，而是四根护栏在五层里都有落点。

带着这张图往下读，每一条铁律你都能在上面找到坐标。

四、核心精髓：四条"反直觉"的铁律

读了几十篇文章、踩了三个月坑之后，我把 Harness 的精髓提炼为四条反直觉的铁律。之所以"反直觉"，是因为它们都和工程师的本能背道而驰。

先用一张表看全貌，再逐条展开：

铁律一：上下文越少越好（不是越多越好）

工程师本能：信息越多决策越准。
Harness 真相：**上下文是稀缺资源，会被污染、会相互干扰、会让模型"逛超市"**。

业内多个团队的实测都指向同一个方向：长上下文窗口在实际使用比例超过一定阈值之后，模型的准确率会显著下降——具体阈值因模型、任务、Prompt 结构差异很大，并不存在一个放之四海皆准的"百分比"。

铁律二：专才 Agent 永远赢过通才 Agent

工程师本能："我做一个超级 Agent，什么都会，不就搞定了？"
Harness 真相：通才 Agent 在工具列表里"逛超市"，永远跑不过一组职责清晰的专才。

LangChain 在 Terminal Bench 实验里给了一条非常具体的经验：把任务拆给专门的 Sub-Agent，并为每个 Sub-Agent 只装载它真正需要的工具，是排名从第 30 冲进第 5 的关键改动之一 [2]。

铁律三：状态要写文件，不要塞上下文

工程师本能：让 Agent "记住"任务进展。
Harness 真相：上下文是易失存储，文件系统才是持久内存。

成熟的 Agent 系统遵循一个简单原则：Workspace 是真相，Context Window 只是当前工位。任务中间结果、Agent 间协作、跨会话延续、审计回放，全部走文件系统。

铁律四：能写成 Linter 的约束，别写成文档

工程师本能：把规则写进 AGENTS.md 让 Agent 自己读。
Harness 真相：**文档只是"建议"，Linter / CI 才是"强制"**。

Mitchell Hashimoto 在他自己的 Ghostty 项目里就给了一个非常硬核的实践：AGENTS.md 里每一条规则，背后都对应一个真实失败案例；而能写成静态检查 / CI 拦截的规则，绝不让它停留在自然语言里——因为自然语言可以被模型"创造性解读"，代码不能 [1]。

五、Context Engineering 的"工程化"：

从"喂信息"到"控信号"

Harness Engineering 不是 Context Engineering 的对立面，而是它的工业化升级。同样是"给模型对的信息"，工程化版本要做四件事：

一旦上下文变成可审计的"输入信号"，你就从"调 Prompt 的玄学"进入了"调系统的工程"——这是 Harness 工程师和 Prompt 工程师最大的分水岭。

六、六大工程模式：

Harness Engineering 的"设计模式手册"

如果说前面的铁律是"心法"，下面六个就是"招式"。它们都已经被多家团队在生产环境验证过，可以直接抄。先给一张索引表，每一行对应下面的一个小节：

模式 1：双阶段架构（Initializer + Executor）

Anthropic 在 Claude Code 的实践中给出了一个被广泛复用的模板：把任务拆成两段——

Initializer Agent：理解任务 → 制定计划 → 写入 plan.md → 退出                                        ↓Executor Agent   ：读取 plan.md → 按步执行 → 跨 Context Window 接力

两个 Agent 不共享 Context Window，只通过 Workspace 里的 plan.md 接力。这样做的好处：任务可以跨多次会话延续，不依赖任何一个会话的记忆。

模式 2：工具签名即文档

（Tool-Signature-as-Doc）

Agent 选错工具的最大原因，不是工具太多，而是工具签名写得像一坨胶水。成熟团队的做法：

• 工具名是动词短语，一眼能读懂："query_calendar" 而不是 "tool_03"。
• 参数 schema 里每个字段都带 description，且描述里说清"什么时候用、什么时候别用"。
• 返回值结构稳定，Agent 不需要每次猜格式。

模式 3：Sub-Agent 隔离

（Context-Isolated Sub-Agent）

复杂任务交给 Sub-Agent，**但关键不是"拆"，是"隔离"**：

• 每个 Sub-Agent 有独立 Context Window，不污染主上下文。
• 每个 Sub-Agent 只看到自己需要的工具，看不到全集。
• 主 Agent 只接收 Sub-Agent 的结构化输出，不接收它的中间思考。

模式 4：上下游反压

（Upstream-Downstream Backpressure）

防止 Agent 陷入无限循环的工程范式：

上游：给确定性设置 + 一致上下文   │   ▼Agent 执行   │   ▼下游：测试 / 类型检查 / Lint / CI 拒绝无效工作   │   ▼错误信号回传 → 上游调整

关键细节：Linter 的错误信息本身就是上下文工程。它不只说"违反规则 X"，而是解释"为什么这个规则存在、正确做法是什么"——这样 Agent 读到错误后就能自我修正，不需要人类介入。

模式 5：智能体审智能体

（Agent-Audits-Agent）

人类做不动 Code Review 的时候，让另一个 Agent 来做。但关键是换 Context：

• Reviewer Sub-Agent 只看 git diff + docs/rules/*.md。
• 角色设定为"怀疑态度的 Senior Reviewer"。
• 它对 Main Agent 的产出一无所知，所以不会被"自我合理化"污染。

经验之谈：失效的从来不是"换一个模型再评估"，而是"用同样的 Context 再评估一次"——后者只会复现同一个偏见。

模式 6：熵管理与文档园丁

代码库的熵会随着时间增长——Agent 比人类增长得更快，因为它擅长"模式复制"，会忠实地复制并放大坏模式。解法：

• 部署一个**后台 Agent 做"文档园丁"**，定期扫描过期文档、检测架构漂移、提交清理 PR。
• 持续小额偿还技术债，不要攒到爆雷。
• 把"垃圾回收"做成定时任务，而不是项目结束的善后。

七、实战案例：悟空 AI 招聘 Agent —— 

一个"专才赢通才"的真实样本

AI钉钉1.1新品发布会

理论铁律说了一大堆，接下来上一个正在生产环境跑的真实案例。这是我们团队在钉钉企业级 Agent「悟空」上落地的 AI 招聘 Agent 系统——它每天处理上千份简历、自动约面试、跟踪候选人状态，已经稳定运行数月。

更重要的是：它一开始差点被我们做废。第一版我们犯了所有新手都会犯的错——造了一个"全能招聘 Agent"。下面这段经历，应该能让你少踩三个月坑。

7.1 直觉反应 ：先造一个"全能招聘 Agent"

立项第一周，团队的第一反应非常自然：

于是我们写了这样一份 System Prompt：

#  第一版：全能招聘 Agentrecruit_agent = Agent(    system_prompt="""你是一个全能招聘助手，你会：- 从 xxx 系统抓取简历- OSS解析 PDF / Word 简历，提取教育背景、工作经历、技能- 做人岗匹配评分（JD vs 简历）- 在xx里和候选人聊天、要简历、约面试- 调用日历查面试官闲忙、订会议室- 给 HR 发提醒、生成日报- 跟踪候选人状态、超时预警- 触发 RPA 在招聘工作台做批量操作- 给候选人发预约AI面试... （Prompt 写了 600+ 行）""",    tools=[        fetch_resume, parse_pdf, parse_docx, score_match,        send_dingtalk_msg, query_calendar, book_room,        create_todo, send_email, trigger_rpa,        upload_file, download_file, query_db,        ...   # 一共 13 个工具    ])

跑了一周，问题全冒出来了：

招聘工作台 RPA 跑到一半，Agent "顺手"去回复了候选人聊天 → 上下文炸了10+ 个工具里挑错工具的概率显著偏高（明明该调 query_calendar，调成了 query_db） Prompt 600 行写到第 400 行，模型已经忘了开头说"不要主动发 Offer"一个会话里干完简历筛选，下一个会话完全不记得这个候选人——状态全在上下文里出错时根本不知道哪一环错了，回滚一次要查 2 小时日志

把第一版的"病灶"画出来，长这样：

用户：帮我处理今天投递的简历，匹配后约面试全能招聘 Agent 的上下文：┌──────────────────────────────────────────┐│ system prompt: 你会简历解析、人岗匹配、    ││ 聊天回复、约面试、查日历、订会议室、       ││ 发邮件、触发 RPA、生成日报…              │ ← 600+ 行│                                          ││ 当前任务: 处理今天的简历                  ││ 历史记录: 上午聊了 5 个候选人 + RPA 日志 │ ← 乱成一锅粥│ 工具列表: 38 个工具                       │ ← 注意力被稀释└──────────────────────────────────────────┘                  ↓           模型在"逛超市"                  ↓       准确率达不到上线门槛，错误难复现

——这正是铁律二（专才 > 通才）和铁律一（上下文越少越好）的双重违反现场。

7.2 第二版：拆成"2 Agent + N Skill"的专才架构

把全能 Agent 推倒，按"Agent 是昂贵的、Skill 是廉价的"[3]这条经验法则重新设计——结果是一个 2 个 Agent + 多个 Skill 的极简架构：

                  ┌────────────────────────────────────────┐                  │       悟空（DingTalk 企业级 Agent）       │                  │  ─────  Orchestrator / 上下文调度  ────  │                  │  · 拆任务  · 分发  · 维护 Workspace      │                  │  · 跨会话记忆（候选人状态写文件）          │                  └────┬─────────────────────────────┬─────┘                       │                             │        ┌──────────────▼──────────────┐ ┌────────────▼─────────────┐        │   人岗匹配 Agent（RPA 专才）  │ │  招聘沟通 Agent（聊天专才）│        │                              │ │                          │        │  职责：                       │ │  职责：                  │        │  · 招聘工作台 RPA 操作        │ │  · 监听候选人聊天     │        │  · JD ↔ 简历 语义匹配评分    │ │  · 自动对话要简历         │        │  · 批量打分 / 排序 / 标记    │ │  · 协商面试时间          │        │                              │ │  · 触发约面 / 改期        │        │  Prompt: 80 行（聚焦）       │ │  Prompt: 90 行（聚焦）   │        │  Tools: 4 个                 │ │  Tools: 5 个             │        └──────────────┬───────────────┘ └────────────┬─────────────┘                       │                              │                       └──────────────┬───────────────┘                                      │                                      ▼                ┌─────────────────────────────────────────┐                │           N 个原子化 Skill              │                │  parse_resume / score_match /           │                │  query_calendar / book_room /           │                │  send_dingtalk / extract_field /        │                │  upload_file / download_file /          │                │  query_ats / write_todo / ...           │                │  （每个 Skill = 一个函数 + 明确签名）     │                └──────────────────┬──────────────────────┘                                   │                                   ▼                ┌─────────────────────────────────────────┐                │       Workspace（真相之源）              │                │  /candidates/{id}/state.json           │                │  /candidates/{id}/chat_history.log     │                │  /jobs/{id}/jd.md                      │                │  /rpa_lock/{batch_id}.json             │                └─────────────────────────────────────────┘

7.3 五条工程铁律是怎么逐条落到这个系统上的

新架构不是"拍脑袋"，每一条选择都对应前面的一条铁律：

最关键的一点：悟空不直接调 n 个工具。它只调"派单"这一个动作——把任务连同精挑过的 3-5 个工具派给专才 Agent。这就把"50 选 1"的选择题，拆成了三道"5 选 1"。

7.4 改造前后的对比：四个维度全胜

7.5 三条"血泪经验"

这套系统跑了数月，沉淀出三条最值得分享的经验。它们都不是"理论推导"，而是踩坑换来的：

经验一：Agent 数量不要超过 3 个，Skill 可以无限加。

我们曾经一度想拆出"日报 Agent"、"简历库 Agent"、"Offer Agent"、"超时预警 Agent"——堆到第 6 个 Agent 时发现，编排层（悟空）开始"选错 Agent"了，错误率明显回升。Agent 数量本身也是上下文成本。后来我们把后面几个全部下沉为 Skill，问题立刻消失。

经验二：RPA + Agent 的接缝处最容易出事，要做"事务边界"。

人岗匹配 Agent 在招聘工作台里做 RPA 操作时，最早会出现"做到一半上下文被打断、状态对不上"的事故。后来我们引入强制性的事务文件：

RPA 开始    → 写 workspace/rpa_lock/{batch_id}.json (state: running)每完成一条  → 追加进度RPA 结束    → 标记 state: done
任何中断    → 下次启动时读 lock 文件，从断点续传，绝不重头跑

这条经验直接对应铁律三——状态写文件，不在脑子里。

经验三：聊天 Agent 必须接"硬护栏"，因为它对外说话。

招聘沟通 Agent 是唯一一个"会主动给真人发消息"的 Agent——这就意味着它的错误是对外暴露的。我们给它套了三层硬护栏：

这三层一摞上，**对外消息的事故率从"每周一两次"降到了"我们已经记不清上一次是什么时候了"**。

八、行业标杆地图：他们是怎么做的？

下面这张表，把当下被广泛讨论的几家代表团队，按"最有辨识度的 Harness 选择"做了一次对位——不是排名，而是"四根护栏在五层里的落点不一样"。

把这张表当作一面镜子：你团队最缺的，往往是表里某一格里的能力——是缺 Workspace？缺反馈回路？还是 AGENTS.md 还是一篇散文？

九、未来：Agent 工程将走向哪里？

下面是基于当前趋势的一组判断，不是预言。每一条都标注了可证伪条件——这是资深工程判断和"预言式断言"的分水岭。

趋势一：从"Prompt 工程师"到"Agent 工程师"

招聘市场上，Prompt 工程师的岗位正在快速被"Agent 工程师 / Harness 工程师 / AI 系统工程师"这类岗位取代。区别在于：

• Prompt 工程师卷的是话术，可被替代性强。
• Harness 工程师卷的是系统——上下文设计、工具签名、反馈回路、状态管理——这些就是软件工程的核心能力。

趋势二：从"工具调用"到"Agent 协作协议"

MCP（Model Context Protocol）的崛起，意味着 Agent 与外部世界的接口正在被标准化。下一步：Agent 之间的协作协议——A2A（Agent-to-Agent）。一旦 A2A 标准化，"多 Agent 系统"就会像"微服务"一样工业化。

趋势三：从"单 Agent 完成任务"到"Agent 操作系统"

一句值得反复咀嚼的判断：

未来三五年，竞争的焦点会从"我的 Agent 多智能"变成"我的 Agent OS 多稳"。这才是真正的护城河。

趋势四：模型与 Harness 的"接口标准化"

随着 Agent 工程进入工业化阶段，模型与 Harness 的接口也会被标准化——比如"工具 Schema 标准"、"上下文交换格式"、"Sub-Agent 调用协议"。未来你换模型可能像换数据库引擎一样简单——前提是你的 Harness 写得足够干净。

十、心法收尾：

六句话送给所有 Agent 工程师

如果你只有 30 秒能记住这篇文章，记住这六句：

十一、写在最后

这两年，AI 圈最大的认知转变是：我们终于承认，模型不是孙悟空，Agent 系统才是。

孙悟空再厉害，没有金箍棒、没有筋斗云、没有紧箍咒、没有取经路线图，他就是一只猴子。

模型再聪明，没有合适的 Harness——它就是一匹脱缰的野马，能跑也能毁。

过去几年，行业花了大量精力训练"更聪明的模型"。

现在，真正拉开差距的——是谁的缰绳更顺手、马鞍更舒服、护栏更结实。

模型还在进步，但单靠等待更强的模型已经不够了。工程能力的差距，正在成为新的分水岭。真正的护城河，是你为这匹野马造的那条高速公路——它决定了你能跑多远、多稳、多快。

Harness Engineering，是 AI 时代软件工程的重新发明。而每一个写过代码、调过 Bug、做过 Code Review 的工程师，都拥有这场革命中最稀缺的资产：对"系统应该如何运转"的直觉。

别再羡慕那些"小团队产出大代码量"的故事了。
他们做对的事，你也能做。 区别只是——你今晚回去，会不会先写第一个 Linter。

参考资料与诚实声明

本文在引用上做了两件事：

1. 能溯源到一手英文资料的论断，明确标注来源链接；
2. 行业广泛流传但一手出处尚未核实清楚的数据（如"小团队 / 数月 / 百万行代码 / 0 手写"等类似数字），文中已主动软化或明确加注"原始报告链接尚待核实"，不作为确定性事实使用。

读者如果发现任何遗漏或更准确的一手出处，欢迎指正。

引用列表

未在本文中引用、但读者可自行检索的相关原始资料方向

• Mitchell Hashimoto 个人网站（mitchellh.com）的博客原文
• Anthropic 关于 Claude Code 的官方技术文章
• OpenAI 工程团队关于内部 Agent 实践的公开发言

千问云-为Agent而生，驱动AI生产力
扫描下方二维码，直达千问云体验

点击阅读原文即可体验！

登录查看剩余 70% 内容