问题很可能不在 AI。本质上是它周围的 harness、loop 和 graph 出了问题，下面用不带术语堆砌的方式解释清楚。
某个环节出问题了。
你的 AI agent 跳过了一个步骤。无限循环。忘了自己在做什么。或者信心十足地完成了错误的任务。
第一反应总是一样的。模型就是不够聪明。
我以前也这么认为。
直到我看到两个团队使用完全相同的模型，处理完全相同的任务，却得到完全不同的结果。
一个 agent 几分钟就完成了。
另一个则惨烈失败。
同样的智能，却是完全不同的结果。那一刻我意识到，模型并不是最大的变量。围绕它构建的系统才是。
它能访问哪些工具。它的工作如何被检查。它被允许以什么顺序思考和行动。
工程师现在把这些拆成三层：
Harness Engineering。
Loop Engineering。
Graph Engineering。
一旦你理解了这三层，AI agent 的失败就不再显得随机。
你会停止责怪模型。而且通常可以在改动任何 prompt 之前，识别出到底是哪个组件出了问题。
把它想象成一名新员工，而不是机器人
先暂时忘掉“AI”这个词。想象一位聪明的新员工第一天入职一家公司。
他的原始天赋是固定的。决定他能否成功的是围绕这份天赋的一切：他是否拿到了能正常工作的笔记本电脑和正确的软件登录权限，是否有人在成果交付之前检查他的工作，以及是否有清晰的流程规定谁审批什么。
AI agent 的工作方式也是一样。模型是原始天赋。另外三件事决定了这份天赋能否转化为可靠的工作成果。
这是三种不同的工作。把它们混在一起，你每次都会修错问题。
Harness：AI 实际被允许做什么
Harness 就像设备间。
它包括 AI 可以使用的工具、可以看到的文件、在不同 session 之间保留的 memory，以及关于它被允许触碰哪些内容的规则。
一个原始 AI 模型本身无法打开文件、运行测试、在浏览器里点击操作，也无法记住昨天发生了什么。所有这些能力，都是由 harness 后续接入进去的。
两个团队可以使用完全相同的模型，却得到非常不同的结果，因为一个团队给了它干净的工作区和清晰的边界，另一个团队只给了它含糊的指令和坏掉的工具。
我旁听过这两类团队的工作，而令人有点不安的是，差距很大程度上来自设备间，而不是大家一直争论的那个模型。
Anthropic 在构建一个需要跨多个 session 工作的 coding assistant 时，就直接遇到了这个问题。
一开始，他们只是尝试总结旧对话来节省空间，这相当于 AI 版本的“到目前为止发生了这些，信我就行”。
这没有撑住。
真正有效的做法更像一个真实的 onboarding 流程：一个解释项目的启动文件、一份持续更新的进度日志，以及留下干净笔记的习惯，让下一个 session 可以准确接上上一个 session 停下的地方。
这就是 harness 工作，简单明了，而且修复方案完全存在于它周围的设备间里。
Loop：工作如何被检查
每个使用工具的 AI agent 其实都已经在运行一个小型 loop：尝试某件事，查看结果，再尝试一次。Loop engineering 指的是你有意识地设计这个循环，而不是把它留给偶然。
一个好的 loop 需要一个清晰目标、一种测试该目标是否达成的方法、在目标未达成时给出诚实反馈的机制，以及一条规定何时停止的规则。
这里有一点大多数人都搞反了：永远不要让 AI 自己决定它已经完成了。我是吃过亏才学到这一点的，当时我看着一个 agent 带着十足信心把一个坏掉的脚本标记为“complete”。它自己的信心不是证据。通过的测试才是证据。一个看过结果并说“可以”的人也是证据。“我觉得这完成了”不属于其中任何一种。
在实践中，这会表现为几种形式。check-and-retry loop 会让 AI 返工，直到它通过真实测试。wake-up loop 只在某件事发生时启动 AI，比如收到新邮件、到达某个日程时间、某个文档落入文件夹，而不是毫无理由地持续运行。improvement loop 会回顾上周失败的内容，并悄悄重写指令，让同样的错误不再发生。不同的工作，同一个底层形态：尝试、检查、学习、重复。
每增加一次检查也都有成本，包括更多时间、更多 compute。因此值得记住的规则很简单：当出错的代价高于检查成本时，就添加一个 loop。
Graph：谁接下来行动的地图
Graph 回答的是一个完全不同的问题：不是 AI 做什么，而是接下来允许发生什么，以及按什么顺序发生。
想象一张 flowchart。方框是步骤。箭头表示什么可以跟在什么后面：一个步骤接着另一个步骤，两个步骤并行运行，几条路径重新汇合为一条，或者在人类介入审批后才继续。
假设你在运行一个 AI 系统，用来研究某个主题并撰写报告。其中一部分负责收集事实。第二部分根据真实来源核查这些事实。第三部分撰写草稿。第四部分在报告发往任何地方之前进行审阅。Graph 要确保写作者不能在 fact-checker 完成之前开始，也要确保最终草稿发布之前必须有人查看。
注意从 review 回到 draft 的 loop。这就是 graph 在发挥作用：报告不能跳过 fact-checker，也不能在没有人类说“可以”的情况下到达“published”，无论它需要回去重试多少次。
当存在真实分支、真实审批，或者多个专家彼此交接工作时，graph 才能体现价值。如果整个任务真的只是“一个 AI、一个工具、开始”，graph 往往只是叠在简单事项之上的额外仪式。在你观察 AI 如何完成工作之前就画地图，通常会画错地图。
即使你从不构建这类系统，为什么也应该关心
我以前以为，一个更顺滑的 AI 产品只是底层悄悄运行着一个更好的模型。后来，当我开始关注这些公司实际发布的关于自身系统的内容时，这个假设就崩塌了。
你可能已经亲身感受过这一点。也许是一个会悄悄检查自己工作的 coding assistant，对比另一个说“done”然后交给你一段根本跑不起来的代码。也许是一个能记住你两分钟前告诉它内容的 support chatbot，对比另一个每条消息都让你重复一遍的 chatbot。
在一个场景里你并不是在和更聪明的 AI 对话，在另一个场景里也不是在和更笨的 AI 对话。大概率是你面对的是同一类模型，只是它被包裹在更好的 harness、更紧的 loop、更干净的 graph 之中，或者完全没有这些东西。
这就是我希望有人更早告诉我的部分：当一个 AI 工具感觉不可靠时，修复工作几乎从来不是从“换一个更聪明的模型”开始。它是从询问这三层里哪一层缺失开始。
团队在不知不觉中搞坏它的五种方式
这些都不是什么罕见错误。我见过聪明且经验丰富的团队把其中每一个都犯过，而且通常不止一次。
第一：还没人观察 AI 尝试任务，就先画 flowchart。二十个精心绘制的步骤看起来很厉害，直到 AI 用六个完全不同的步骤解决了问题，而任何东西都对不上。先看它怎么工作。只把那些最终证明稳定的路径形式化。
第二：让 AI 给自己的作业打分。让 AI 检查自己的输出，会共享导致最初错误的同一套盲点。真正的测试需要来自模型之外，而不是问它“你确定吗？”
然后是把“继续尝试”写成整个计划。一个没有限制、也没有清晰终点的 retry loop 解决不了任何问题，它只是在绕圈花钱。
还有一种：把设备间当成杂物抽屉。更多工具和更多 memory 听起来像升级，但拥挤的工具箱实际上会让 AI 更频繁地选错工具，而不是更少。
最常见的错误则是：当 AI 周围的流程坏掉时，却责怪 AI。过时的笔记、不清楚的指令、没有停止规则，把一个更聪明的模型放进同样的线路里，它仍然会犯完全相同的错误。
一个 60 秒检查你正在使用的任何 AI 工具的方法
下次某个 AI 工具让你失望时，在判定 AI 本身有问题之前，先过一遍这个检查。
这些问题都不是通过切换到一个“更聪明”的模型来修复的。它们是通过修复出故障的那一层来解决的。
要点总结
回到本文开头那个坏掉的 AI agent。模型很可能从头到尾都没问题。真正的罪魁祸首恰好位于三个地方之一：设备间、检查流程，或者步骤地图。
模型是天赋。harness、loop 和 graph 才是工作本身。一个才华横溢的新员工如果没有笔记本电脑、没有 manager、没有 org chart，依然会失败，而没人会因此责怪他的智力。
现在，当一款 AI 软件让我失望时，我最常问自己的问题几乎就是这个：三层之中到底哪一层坏了？下次某个基于 AI 构建的东西让你失望时，也试试看。这是个很小的习惯，却让我对那些原本就不是问题所在的工具少了很多恼火。
参考资料与延伸阅读
Anthropic, "Building Effective AI Agents"
LangChain, "The Anatomy of an Agent Harness"
LangChain, "The Art of Loop Engineering"
LangChain, "LangChain and LangGraph Reach Their v1.0 Milestones"
OpenAI, "Agents SDK Guide"
OpenAI, "A Practical Guide to Building Agents"
Microsoft, "GraphFlow (Workflows), AutoGen Documentation"
Microsoft Research, "Introducing AutoGen Studio"