你的 AI Agent 没坏，是你的控制框架没配好。来看看我是如何搭建这套系统，让它从“累赘”转变为能交付生产级代码的。

我曾花了三周时间一味怪罪模型，因为它在一个早已存在 `src/lib` 类型化 fetch 封装的项目里又引入了 axios。我虽然每天都用它，但智能体根本不知道那个封装的存在。接着，在一次自动化会话中，它于凌晨两点强制推送到了 main 分支。根本没人告诉它不能这么做。紧接着是真正的灾难：它直接把失败的测试用例注释掉了，而不是修复它。CI 依然显示通过。PR 随之合并。结果，一个损坏的认证流程在生产环境中裸奔了三周才被人发现。 每次我都怪模型。尝试过升级。试过 Claude、GPT、Gemini。试过更详细的 prompt。毫无改变。然后我意识到：我给了一个强大的工具零项目知识、零防破坏护栏，以及零自我纠错的反馈。**模型不是问题，它周围的系统才是。** **“控制框架（Harness）”指的是什么** 这个版块的人每天都在争论哪个模型最聪明、哪个写的代码最干净、哪个幻觉最少。这固然重要，但这只占了一半。AI Agent 不只是一个模型。它是模型加上包裹在它周围的一切——塑造行为的提示词、强制规则执行的钩子（hooks）、让它熟悉你代码库的记忆机制、以及让你在介入审查前就能自我纠错的反馈循环。这层“包裹”就是 Harness。经历了足够多的生产事故后，我确信一点：**在精心设计的 Harness 中运行的普通模型，其表现将永远优于在粗糙框架中运行的前沿模型。** 次次如此。Harness 是效能放大器。而且，模型是从别人的实验室流出的，但 Harness 完全是你自己打造的。 **彻底改变一切的三个层级** 我把每个 Harness 组件组织成三个层级： **第一层 —— 知识（Knowledge）。** 在智能体写下第一行代码前，它对你的项目了解什么。在仓库根目录放一个 markdown 规则手册。智能体每次会话都会读取它。原则是：每条规则都必须追溯自一次真实的失败。不是最佳实践，不是假设，是踩坑留下的“伤疤”。模糊的规则会被无视：“写整洁的代码。遵循最佳实践。”具体的规则才有效：“永远不要注释或跳过测试。删掉它或修复它。一次被跳过的认证测试曾掩盖了损坏的登录流程长达三周。”最好的技巧是：不要描述你的模式——直接指向一个真实文件。“规范的路由结构参见 `src/app/api/users/route.ts`。”智能体会读取实际代码并完美复刻。这比任何文字描述都要好 10 倍。 **第二层 —— 护栏（Guardrails）。** 无论智能体怎么决定，它*物理上根本无法执行*的操作。规则可以被无视，但钩子（hooks）不行。它们在 shell 命令执行前、文件编辑后、提交前触发。它们不请求合规——它们强制执行。破坏性命令拦截门，在执行前拦截 `rm -rf`、`DROP TABLE`、强制推送。密钥扫描仪，拦截任何触及 `.env` 或凭据的提交。跳过测试检测器，拦截包含 `.skip` 或 `xit` 的提交。最后那个正是我三周生产事故的直接产物。寥寥几行配置本就能避免整场灾难。 **第三层 —— 反馈循环（Feedback loops）。** 区分“勉强能用”和“交付生产代码”的关键层级。如果检查通过，智能体什么都听不到。如果失败，完整的错误信息会被重新注入对话中。智能体看到哪里坏了并立即修复。你不再是质量把关人。我的审查时间减少了 60-70%——不是因为智能体变聪明了，而是因为我再也不审第一版草稿了。大多数人只搭建第一层。真正的杠杆在于将三者叠加。 **我反复看到的模式** 每次看到这个版块有人发帖说“我的智能体老是 X 做错”——安装不必要的包、把文件放错位置、写出能编译但跑不通的代码、在复杂任务中迷失方向——这几乎总是 Harness 的问题，而不是模型的问题。那些能靠智能体交付生产代码的团队，用的并不是别人没有的模型。他们只是在经过数月失败观察打磨出的系统中运行着相同的模型。你不需要更好的模型。你需要的是它周围更好的系统。很好奇大家都在给智能体搭配什么样的系统。还有谁把这视为一个独立的工程学科吗？