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

↑ 凌晨两点：屏幕上 "ALL TESTS PASSED"，红色警告悄悄写着 "3 services deleted"——这就是这两年开发者最熟悉的"虚假胜利"瞬间。野马已经冲出了显示器，而你手里没有缰绳。

凌晨两点，你盯着屏幕。Agent 又一次"自信地"宣布任务完成——测试全绿、CI 全过、PR 描述写得无懈可击。你点开 diff，发现它把一个核心服务"重构"了，顺手删掉了三个它"不理解"的兼容分支。

或者，更扎心的场景：

• 一个会话里它表现得像高级架构师，下一个会话像刚入职的实习生，因为它压根不记得上次干了什么。
• 你给它配了 20 个 MCP 工具，它开始在工具列表里"逛超市"，逛着逛着就忘了正在干嘛。
• 它陷入死循环，把同一个错误反复"修复"了十几次，每次都换一种"自信"的说法。
• 你写了一份 800 行的 AGENTS.md 教它做事，它读完前 200 行就开始幻觉。

如果你点头了——欢迎来到 Agent 的"实战时代"。这一年，AI 工程圈终于承认了一件事：

瓶颈不在模型够不够聪明，而在我们有没有把它"装"好。

这就是 Harness Engineering（驾驭工程）——Terraform / HashiCorp 联合创始人、Ghostty 终端作者 Mitchell Hashimoto 在他个人博客《My AI Adoption Journey》中系统阐述的工程范式 [1]。他给这件事的定义朴素到几乎是一句口号：

"anytime you find an agent makes a mistake, you take the time to engineer a solution such that the agent will not make that mistake again in the future."

——每当你发现 Agent 犯了一个错，就花时间工程化一个解，让它将来不再犯同样的错。

这句话本身就是 Harness Engineering 的全部精神：Agent 的每一次失败，都不是模型的问题，而是环境设计的债。

如果你只能记住这篇文章的一句话，请记住这个：

Agent = Model + Harness

这个公式后来被 LangChain 官方在《Improving Deep Agents with Harness Engineering》一文中作为标题级别的论断 [2]：模型负责推理，Harness 负责"剩下的所有事情"——工具系统、上下文管理、权限控制、反馈回路、记忆与协作。

这个公式的颠覆性在于它彻底改变了优化方向。最值得拿出来讲的一手案例，是 LangChain 自己做的实验：

表格数据说明：LangChain 一行来自官方博客 [2]，一手可查；Anthropic 一行为行业公认事实；"小团队"一行仅作现象记述，未核实到一手来源。

读到这里你应该意识到一件事：过去几年大量精力放在"换更强的模型"上，但真正的杠杆位置一直在模型之外。

↑ 三代范式的进化路径：从"对马喊话"到"给马看地图"，再到"给马造高速公路"——这两年里，AI 工程的关注焦点完成了从「话术」到「环境」的彻底跃迁。

这是 AI 工程范式的进化时间轴，对照一下你团队的水位：

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

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

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

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

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

↑ 四张卡片就是后文所有工程模式的"DNA"：上下文要少、Agent 要专、状态要落盘、约束要可执行。每一条都和工程师的本能反着来——而这正是它们值钱的原因。

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

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

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

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

启示：不要把"模型支持 200K"当成"可以塞 200K"。给 Agent 的上下文，必须像 Code Review 一样精挑细选。

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

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

启示：Agent 是昂贵的，Skill 是廉价的 [3]——能用 Skill 解决的就别新增 Agent。

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

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

启示：把 Workspace 当成"Agent 的 Git 仓库"——每一步操作都可回放、可审计、可断点续传。

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

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

启示：把规则编码为机器可执行的约束，比"再写一段更详细的 Prompt"更可靠十倍。

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

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

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

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

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

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

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

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

LangChain 在 Terminal Bench 实验里专门提到：仅仅改善工具描述与返回结构，就能带来可观的准确率提升 [2]。

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

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

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

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

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

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

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

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

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

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

AI钉钉1.1新品发布会

数据声明：以下所有数字（准确率、上下文消耗、工具数量等）均来自我们团队在内部环境下的实测，仅代表本场景。不同业务、不同模型、不同流量下数字会有显著差异。我们公开这些数字不是为了树立基准，而是为了让你看清"专才架构"和"全能 Agent"在同一组评测下的相对差距。

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

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

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

"招聘流程不就那几步吗？投递、筛选、面试、Offer——我做一个超级招聘 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 个工具                       │ ← 注意力被稀释└──────────────────────────────────────────┘                  ↓           模型在"逛超市"                  ↓       准确率达不到上线门槛，错误难复现

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

↑ 一张图说清楚我们踩过的最大的坑：左边是想用一个机器人扛下 38 个工具的"全能 Agent"（结果在工具堆里逛超市）；右边是悟空作为 Orchestrator 协调 2 个专才 Agent + 多个 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             │                └─────────────────────────────────────────┘

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

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

下表所有相对评价都是本场景实测，仅作"改造前 vs 改造后"的相对参考，不代表行业基准。

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

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

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

一个能跑的招聘系统：2 个 Agent + 一组 Skill——远比"多 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 还是一篇散文？

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

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

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

可证伪条件：如果 12 个月内，Prompt 工程师岗位数量重新增长且薪资中位数显著回升，则本判断需要修正。

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

可证伪条件：如果两年内没有任何被主流 SDK 采用的 A2A 草案，则该趋势节奏需要延后。

↑ Agent 系统正在长成一台"新的计算机"：Shell 是用户交互，Scheduler 是编排层，System Calls 是 Skill 能力。

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

Agent 系统是一种新的计算操作系统。用户交互层是它的 Shell，编排层是它的 Scheduler，能力层是它的系统调用，Workspace 是它的文件系统，MCP 是它的设备驱动。

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

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

如果你只有 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生产力
扫描下方二维码，直达千问云体验

点击阅读原文即可体验！