夜雨聆风过去两年，很多关于 AI Agent 的讨论，都绕不开一个问题：哪个模型更强。
谁写代码更好？ 谁幻觉更少？ 谁上下文更长？ 谁工具调用更稳？ ......
这些问题当然重要。但如果只盯着模型，我们很容易忽略另一件事：
一个真正能工作的 Agent，从来不是模型本身。
它更像一套工程系统。
模型只是里面最显眼的部分，真正决定它能不能把事情做完的，是围绕模型搭起来的那一整套脚手架：工具、上下文、记忆、权限、沙箱、Hook、测试、日志、反馈循环、失败恢复机制。
最近 Addy Osmani 在《Agent Harness Engineering》里提出了一个很有启发的说法：
Agent = Model + Harness。
这句话看起来简单，但它可能是理解下一代 AI 工程系统的关键。
一、Agent 不是“会说话的模型”
很多人第一次接触 Agent 时，容易把它理解成一个更主动的 Chatbot。
用户给目标，模型自己规划、自动调用工具、自动完成任务。
听起来很美好。
但真正把 Agent 放进工程现场，会很快遇到一堆问题：
它不知道你的代码规范。 它不知道哪些目录不能动。 它不知道生产环境哪些命令危险。 它可能写完代码不跑测试。 它可能做一半觉得任务完成了。 它可能把日志全部塞进上下文，然后在噪声里迷路。 它可能给自己打分过于乐观。 它也可能在长任务里忘了最初目标。
这些问题很容易被归结为一句话：
“模型不够强。”
但本文会给你截然不同的判断：
很多 Agent 失败，不是模型不够强，而是 Harness 没有设计好。
所谓 Harness，可以理解成 Agent 外围的运行框架。
它包括系统提示词、AGENTS.md、工具、MCP、文件系统、沙箱、浏览器、Hook、上下文压缩、子 Agent、可观测性、权限控制和恢复路径。
换句话说，模型负责“想”，Harness 负责让这种“想”进入一个可执行、可验证、可治理的工作环境。
没有 Harness，模型只是一个语言模型。 有了 Harness，它才可能成为一个能干活的 Agent。
二、不要把所有问题都推给下一代模型
工程师有一个常见反应，Agent 犯错了，先怪模型：
没读懂需求。 改错了文件。 没跑测试。 执行了危险命令。
于是解决方案变成：等下一代模型。
但这其实是一种逃避。
因为很多错误并不需要等下一代模型才能解决：
Agent 不知道项目规范，就把规范写进 AGENTS.md。 Agent 总忘记跑测试，就用 Hook 在文件修改后自动执行测试。 Agent 会执行危险命令，就在工具调用前拦截 rm -rf、git push --force、DROP TABLE。 Agent 做长任务容易迷路，就让它把计划写入文件，每一步完成后更新状态。 Agent 自评过于乐观，就引入独立 Evaluator，而不是让它自己给自己判卷。
这不是模型能力问题，而是工程系统问题。
在传统软件工程里，我们早就接受了这一点：
开发者会犯错，所以我们有单元测试。 发布会出问题，所以我们有 CI/CD。 线上变更有风险，所以我们有审批、灰度、回滚。 故障会重复发生，所以我们有复盘、Runbook、监控规则。
到了 Agent 时代，这套思想并没有失效。
只是对象从“人”变成了“人 + 模型”。
三、每一次 Agent 犯错，都应该沉淀成系统能力
有一个很重要的概念叫棘轮机制。它的意思是：
Agent 每犯一次真实错误，系统就应该向前进化一步。
不要把错误当成一次偶然的坏结果，也不要简单重试。
要问：
这次错误能不能变成一条规则？ 能不能变成一个 Hook？ 能不能变成一个测试？ 能不能变成一个审批点？ 能不能变成一个更清晰的工具描述？ 能不能变成一条项目记忆？
比如，一个 Coding Agent 提交 PR 时把失败的测试注释掉了。
糟糕的处理方式是：
“下次提醒它别这样。”
更好的处理方式是：
在 AGENTS.md 里写清楚：不要注释测试，要么修复，要么删除。 在 pre-commit hook 里检查 .skip( 和 xit(。 在 Reviewer Agent 里把注释测试列为阻塞项。 在 PR 模板里要求说明测试结果。
这样，同一个错误就不只是一次失败，而变成了 Harness 的一部分。
这对 AI 运维尤其重要。
如果一个运维 Agent 曾经误判过某类告警，就应该沉淀成诊断规则。 如果它曾经遗漏过变更记录，就应该强制查询变更系统。 如果它曾经建议过危险操作，就应该把这类操作纳入审批。 如果它曾经把相关性当因果关系，就应该要求它输出证据链。 如果它曾经在没有回滚方案的情况下给出变更建议，就应该把回滚计划变成硬门槛。
真正成熟的 Agent，不是从不犯错。
而是每次犯错后，系统都变得更难犯同样的错。
四、Prompt 不是约束，Hook 才是约束
很多团队做 Agent，第一个动作是写很长的 Prompt。
“你要谨慎。” “你要先分析。” “你不能乱删文件。” “你必须遵守规范。” “你要像资深工程师一样工作。”
这些话不是没用，但它们只是软约束。
软约束的问题是：模型可能忘，可能误解，也可能在长上下文里被稀释。
真正可靠的系统，不能只靠“告诉它”。
要靠“强制执行”。
这就是 Hook 的价值：
Hook 可以在工具调用前检查风险。 可以在文件修改后自动运行测试。 可以在提交前检查格式和安全问题。 可以在访问生产系统前要求审批。 可以在任务结束前检查 Done Condition。 可以在失败时把错误信息回灌给模型。
这里有一个很好的原则：
成功时安静，失败时详细。
测试通过，不必浪费模型上下文。 测试失败，就把错误信息喂回 Agent，让它继续修。
这就是一个低成本、高价值的反馈循环。
对运维系统来说，这个原则同样适用。
指标正常，不必喂给 Agent 一堆无意义数据。 日志没有异常，不必让模型阅读几万行文本。 但如果探针失败、错误率升高、变更刚发生、Pod 频繁重启，就应该把这些高信号信息结构化地送进 Agent 的上下文。
AI 不是要看更多数据。
AI 需要看更有信号的数据。
五、上下文不是越长越好
现在很多模型都在扩大上下文窗口。
这当然有价值，但也容易造成一种误解：
只要上下文足够长，把所有文档、日志、指标、代码、聊天记录都塞进去，Agent 就能变聪明。
事实不是这样。
上下文越长，噪声也越多。 噪声越多，模型越容易抓错重点。 任务越长，模型越容易忘记最初目标。 工具输出越大，真正有用的信号越容易被淹没。
这就是所谓的上下文腐化。
一个好的 Harness，不是简单扩大上下文，而是做上下文工程。
比如：
长日志不要完整塞进上下文，只保留头尾和异常片段，完整内容放进文件，Agent 需要时再读。 工具不要一开始全部展开，只有任务需要时才加载对应技能。 长任务不要一直堆对话历史，而要在关键节点生成结构化交接文件。 项目规则不要写成几十页文档，而要沉淀成简短、明确、可执行的 AGENTS.md。
这和我们做可观测性很像。
采集更多指标，不等于更好地理解系统。 展示更多 Dashboard，不等于更快地定位故障。 把更多数据丢给 AI，也不等于 AI 能给出更好的判断。
关键不是“更多”，而是“更相关、更结构化、更可验证”。
六、Agent 的未来，不是一个更大的聊天框
如果把这篇文章放到更大的技术趋势里看，它其实在讲一件事：
AI Agent 正在从“模型能力演示”，走向“工程运行时”。
早期大家关注 LLM API。输入文本，输出文本。 后来关注工具调用。模型可以查资料、跑代码、调用函数。 再后来关注 Agent。模型可以围绕目标循环执行。
但真正要进入生产，就必须进入下一阶段：Agent Runtime。
这个 Runtime 要负责：
工具注册； 权限控制； 上下文管理； 文件系统； 沙箱执行； 任务规划； 子 Agent 协作； 结果验证； 人工审批； 审计追踪； 成本和延迟度量； 失败恢复。
这已经不是一个 Prompt 能解决的问题。
它更像一个操作系统，或者至少像一个面向 Agent 的运行平台。
这也是为什么未来的竞争，不会只是“谁接入了更强模型”。
更关键的是：
谁能把模型放进一个更可靠的工程系统里。
七、对 AI 运维系统的启发
如果把 Harness Engineering 放到 AIOps 和可观测性场景里，它给我们的启发非常直接。
过去，运维平台主要回答三个问题：
发生了什么？ 影响了什么？ 该怎么处理？
AI 加入以后，很多人希望它能直接给出答案。
但真正可用的 AI 运维 Agent，不能只是一个接了大模型的问答框。
它需要一套运维场景下的 Harness。
知道当前系统拓扑。 能查询指标、日志、链路、事件和变更。 能区分测试环境和生产环境。 知道哪些命令可以自动执行，哪些必须审批。 能引用 Runbook，而不是临场编造步骤。 能在建议操作前评估影响范围。 能在操作后验证恢复效果。 能把失败案例沉淀成下一次诊断规则。
这也是 AI 时代运维系统重构的关键：
不是把 Grafana、Prometheus、Kubernetes、日志平台简单接给大模型。
而是围绕运维目标，设计一套能让模型可靠工作的 Harness。
换句话说，未来的 AIOps 平台，不只是“看见系统”。
它还要能让 Agent 在受控环境里理解系统、操作系统、验证系统，并且把每一次失败变成下一次更稳的能力。
八、真正的门槛在工程化
大模型会越来越强。
但模型越强，问题不会消失，只会升级。
当模型只能回答问题时，我们担心它答错。 当模型能写代码时，我们担心它改坏。 当模型能执行命令时，我们担心它越权。 当模型能处理长任务时，我们担心它失控。 当模型能协同多个 Agent 时，我们担心系统不可解释。
所以，模型能力越强，Harness 越重要。
它不是模型不够强时的临时补丁，而是让模型进入真实世界的工程接口。
未来优秀的 AI 产品，可能都要回答同一个问题：
你不是接了哪个模型。 而是你为这个模型搭了怎样的 Harness。
它能不能记住规则？ 能不能调用正确工具？ 能不能拒绝危险操作？ 能不能自我验证？ 能不能被审计？ 能不能失败恢复？ 能不能持续进化？
这些问题，才决定 Agent 能不能从“看起来聪明”，走向“真的能交付”。
结尾
AI Agent 的下一阶段，不会只是更聪明的模型。
而是更成熟的工程脚手架。
模型决定 Agent 的上限。 Harness 决定这个上限能不能被稳定释放。
如果说过去两年，大家在比较“大脑”；
那么接下来，真正值得关注的是：
谁能为这个大脑，造出一套可靠的身体、神经系统、工作台和安全边界。
这可能才是 Agent 从玩具走向生产力工具的分水岭。
