给野马套上缰绳：Agent Harness 工程实践

三代范式跃迁

文章将 AI 工程的进化划分为三代：第一代 Prompt Engineering 关注"怎么把话说清楚"；第二代 Context Engineering 关注"怎么给 AI 喂对信息"；第三代 Harness Engineering 关注"怎么让 Agent 可控地工作"。

作者用了一个生动类比：Prompt 是对马喊话的技巧，Context 是给马看的地图，Harness 是给马造高速公路并配护栏、限速牌和加油站。这个类比的核心洞察是——关注焦点完成了从"话术"到"环境"的彻底跃迁。

文章依据：Mitchell Hashimoto 博客 [1] 系统阐述 Harness Engineering 范式；LangChain 官方博客 [2] 将 Agent = Model + Harness 作为标题级论断。业内常被引用的类比：模型是 CPU，Harness 是操作系统。

影响：对于正在投入大量资源"换更强模型"的团队，这篇文章提供了一个认知转向——真正的杠杆位置一直在模型之外，在 Harness 的工程化程度上。

四条反直觉铁律

铁律一：上下文越少越好。工程师本能认为信息越多决策越准，但上下文是稀缺资源，会被污染、会相互干扰、会让模型在工具列表里"逛超市"。文章强调不存在放之四海皆准的"百分比阈值"，但给出了明确方向：把上下文当 Code Review 一样精挑细选。

铁律二：专才 Agent 永远赢过通才 Agent。核心经验法则是"Agent 是昂贵的，Skill 是廉价的" [3]——能用 Skill 解决的就别新增 Agent。LangChain Terminal Bench 实验中，将任务拆给专门 Sub-Agent 并只装载必要工具，是排名跃升的关键改动之一。

铁律三：状态要写文件，不要塞上下文。上下文是易失存储，文件系统才是持久内存。Workspace 是真相，Context Window 只是当前工位。文章建议把 Workspace 当成"Agent 的 Git 仓库"。

铁律四：能写成 Linter 的约束，别写成文档。文档只是"建议"，Linter/CI 才是"强制"。Mitchell Hashimoto 在 Ghostty 项目中的实践：AGENTS.md 每一条规则背后都对应一个真实失败案例，能写成静态检查的规则绝不停留在自然语言。

文章依据：铁律一引用了业内多团队实测方向（但承认具体阈值因模型差异很大）；铁律二直接引用 LangChain 实验 [2] 和专家博客 [3]；铁律四引用 Mitchell Hashimoto 的 Ghostty 实践 [1]。

影响：这四条铁律对所有使用 Agent 的团队都有直接指导意义。它们的核心共性是：把"靠模型自觉"替换为"靠工程强制"。

六大工程模式

文章将铁律展开为六个可操作的"设计模式"：

模式 1：双阶段架构（Init + Exec）。Initializer Agent 理解任务并写入 plan.md，Executor Agent 读取 plan.md 按步执行。两者不共享 Context Window，只通过 Workspace 文件接力——任务可以跨多次会话延续。

模式 2：工具签名即文档。工具名是动词短语（query_calendar 而非 tool_03），参数 schema 每个字段带 description 且说清何时用何时不用，返回值结构稳定。LangChain 实验证明仅改善工具描述就能带来可观准确率提升。

模式 3：Sub-Agent 隔离。每个 Sub-Agent 有独立 Context Window，只看到自己需要的工具，主 Agent 只接收结构化输出而非中间思考。

模式 4：上下游反压。Linter 的错误信息本身就是上下文工程——不只说"违反规则 X"，而是解释"为什么这个规则存在、正确做法是什么"，让 Agent 读到错误后能自我修正。

模式 5：智能体审智能体。Reviewer Sub-Agent 只看 git diff + rules，角色设定为"怀疑态度的 Senior Reviewer"，对 Main Agent 产出一无所知以避免自我合理化污染。

模式 6：熵管理与文档园丁。后台 Agent 定期扫描过期文档、检测架构漂移、提交清理 PR，持续小额偿还技术债。

文章依据：模式 1 引用 Anthropic Claude Code 实践；模式 2 引用 LangChain [2]；模式 4-5 引用 Cursor/Cline 内置反馈回路实践。六大模式均标注为"被多家团队在生产环境验证过"。

影响：这是一份可直接"抄"的设计模式手册。每个模式都对应明确的读者问题和解决路径。

悟空 AI 招聘实战

第一版（失败）：一个全能招聘 Agent，System Prompt 写了 600+ 行，挂载 13 个工具（fetch_resume、parse_pdf、score_match、send_dingtalk_msg、query_calendar、book_room 等）。结果：RPA 跑到一半 Agent "顺手"去回复候选人导致上下文爆炸；10+ 工具里选错工具概率显著偏高；Prompt 第 400 行模型已忘了开头"不要主动发 Offer"的约束；出错时回滚一次要查 2 小时日志。

第二版（成功）：按"Agent 是昂贵的、Skill 是廉价的"原则重构为 2 Agent + N Skill 架构。悟空作为 Orchestrator 负责任务拆分和上下文调度；人岗匹配 Agent（RPA 专才，Prompt 80 行，4 个工具）负责 JD 匹配和批量打分；招聘沟通 Agent（聊天专才，Prompt 90 行，5 个工具）负责候选人对话和约面；N 个原子化 Skill（每个 = 一个函数 + 明确签名）负责具体操作；Workspace 文件作为真相之源。

文章依据：所有数字（准确率、上下文消耗、工具数量）均来自团队在内部环境下的实测，文章声明"仅代表本场景"。相对评价为"改造前 vs 改造后"对比，不代表行业基准。端到端准确率从"达不到上线门槛"变为"稳定超过上线门槛"。

影响：这个案例的价值在于它不是理论推演——四条铁律在一个真实的企业级系统里逐条对应、逐条验证。特别是"悟空只调派单这一个动作"的设计，把"50 选 1"拆成了三道"5 选 1"。

三条血泪经验

经验一：Agent 数量不超过 3 个，Skill 可以无限加。团队一度堆到 6 个 Agent（日报 Agent、简历库 Agent、Offer Agent、超时预警 Agent 等），编排层开始"选错 Agent"，错误率回升。把后面几个全部下沉为 Skill，问题立刻消失。Agent 数量本身也是上下文成本。

经验二：RPA + Agent 接缝处要做"事务边界"。引入强制性事务文件：RPA 开始时写 rpa_lock/{batch_id}.json（state: running），每完成一条追加进度，结束时标记 done。任何中断下次启动读 lock 文件从断点续传。对应铁律三。

经验三：聊天 Agent 必须接硬护栏。招聘沟通 Agent 是唯一对外发消息的 Agent，套了三层硬护栏：白名单工具（只能调 send_dingtalk_text/template）、Linter 拦截（敏感词/合规规则）、第二个 Agent 审稿（独立 Context 判断是否冒犯候选人/暴露薪资/暗示录用）。事故率从每周一两次降到"记不清上一次是什么时候"。

文章依据：三条经验均来自悟空 AI 招聘系统的数月运行沉淀，作者明确声明"不是理论推导，而是踩坑换来的"。事故率下降为团队自述数据。

影响：对任何对外交互的 Agent 系统，这三条经验直接可复用。特别是"对外说话和动用户数据的地方，硬护栏要早一步到位"。

未来趋势判断

趋势一：从 Prompt 工程师到 Agent 工程师。Prompt 工程师卷的是话术（可替代性强），Harness 工程师卷的是系统（上下文设计、工具签名、反馈回路、状态管理）。可证伪条件：12 个月内 Prompt 工程师岗位数量重新增长且薪资中位数显著回升。

趋势二：从工具调用到 Agent 协作协议。MCP 标准化 Agent 与外部世界的接口，下一步是 A2A（Agent-to-Agent）协议，使多 Agent 系统像微服务一样工业化。可证伪条件：两年内无主流 SDK 采用的 A2A 草案。

趋势三：从单 Agent 到 Agent 操作系统。Agent 系统是一种新的计算操作系统——用户交互层是 Shell，编排层是 Scheduler，能力层是系统调用，Workspace 是文件系统，MCP 是设备驱动。可证伪条件未显式给出。

趋势四：模型与 Harness 接口标准化。工具 Schema 标准、上下文交换格式、Sub-Agent 调用协议将逐步建立，换模型可能像换数据库引擎一样简单。可证伪条件未显式给出。

文章依据：作者明确声明"基于当前趋势的一组判断，不是预言"，并为前两个趋势提供了可证伪条件。趋势三引用了"Agent OS"类比，为行业常见论述。

影响：趋势一和二对职业规划和技术选型有直接参考价值。标注可证伪条件本身是"资深工程判断和预言式断言的分水岭"。