公众号名称：架构师带你玩转AI

作者名称：AllenTang

发布时间：2026-06-09 22:01

2026 年，AI 圈最火的词是 Agentic Engineering。

Karpathy 在 2 月给了这个时代一个名字：

“你 99% 的时间不在写代码。你在编排 Agent，充当监督者。”

3 月 7 日，他把这件事推到了极致——推送了一个 630 行的 Python 脚本，然后去睡觉了。第二天早上，Agent 跑了 50 个实验，发现了更好的学习率，自己提交了代码。没有人类干预。

这个项目叫 AutoResearch，发布后 21,000 个 GitHub Star，860 万次观看。

但很多人看热闹，没看懂里面的工程核心。

它本质上是一个 while 循环

Anthropic 的官方文档里有一段话，读起来平淡无奇，但是说清楚了一切：

“Agent 通常只是 LLM 在循环中根据环境反馈使用工具。”

while True:
response = llm.call(context)
if response.stop_reason == "end_turn":
break  # 任务完成，退出循环
if response.stop_reason == "tool_use":
result = execute_tool(response.tool_call)
context.append(result)  # 把结果加回上下文，继续

这就是 Agent Loop 的全部。

一个请求，判断停止原因，执行工具，把结果塞回上下文，再发下一个请求。重复，直到模型说”我做完了”。

没有魔法。就是 while 循环。

Loop循环的五个阶段

所有 Agent Loop，不管用什么框架、调什么模型，本质上都在重复同样的五个阶段：

感知（Perceive）：接收输入，组装上下文。用户说了什么，工具返回了什么，记忆里有什么，现在的状态是什么——这些信息组成模型这一轮能”看到”的东西。

推理（Reason）：模型读上下文，决定下一步做什么。是调工具？还是直接回答？还是需要更多信息？这一步完全在模型内部，你看不到，但它决定了接下来的一切。

规划（Plan）：对于复杂任务，模型在行动之前先规划。一次性规划全部步骤（Plan-then-Execute），还是每步推理一次（ReAct），是最重要的架构选择。

行动（Act）：调工具，执行命令，调 API，写文件。这一步真正改变了外部世界的状态。

观察（Observe）：获取行动的结果，注入上下文，进入下一轮循环。

这五步，反复，直到停止条件触发。

循环的停止条件：最被忽视的工程问题

写一个能跑的循环很容易。写一个知道什么时候该停的循环，很难。

停止条件设计得不好，是生产中大多数 Agent 问题的根源：

停得太早：任务没完成，模型说完成了。模型被训练成”有帮助”，倾向于汇报成功，即使任务还没做完。

停不下来：循环陷入了局部状态，一直在重复相同的操作，每次都觉得”再试一次就能成功”。没有外部约束的循环，可以无限消耗资源。

停在了错误的地方：任务完成了一半，遇到了需要人决策的节点，但循环没有设计 Human-in-the-Loop 的检查点，直接用模型的判断替代了人的判断。

Karpathy 的 AutoResearch 对这件事的处理非常干净：停止条件不依赖模型自我判断，而是让外部验证决定循环是否继续。

Harness 工程：Loop 外面的那层

只把循环写稳，还不够。

循环需要一个运行环境——知道什么时候介入，出了问题怎么恢复，结果对不对，成本有没有失控。这一层叫 Harness。

想象一台发动机（Loop）装进一辆车。发动机负责运转，但还需要方向盘、刹车、仪表盘——这些东西不在发动机里，但没有它们，发动机跑起来是危险的。Harness 就是这些东西。

Agent = Model + Harness

有数据支撑这个判断：2026 年，有团队只改了 Harness、完全没有换模型，编程基准测试上取得了最高 10 倍的性能提升。

Loop 和 Harness 的分工是这样的：

Loop 负责：推理 → 工具调用 → 观察 → 再推理（循环内部）
Harness 负责：
├── 循环开始前：上下文怎么组装，工具怎么准备
├── 循环中途：结果验证，预算监控，人工介入点
├── 循环结束后：状态持久化，日志记录，经验沉淀
└── 循环出错时：重试策略，熔断，错误上报

Karpathy 的 AutoResearch 之所以只用 630 行就做到了让 Agent 过夜跑实验，不是因为代码聪明，而是因为 Loop 和 Harness 都做得足够干净：

• 上下文只保留最重要的内容（context.md 精炼摘要）

• 停止条件是外部客观指标，而不是模型自我判断

• 失败路径有回滚机制（git revert）

Loop 工程的精髓——不是让循环更聪明，而是让循环更可控。Harness 是那个”可控”的实现。

FDE：把 Loop + Harness 装进真实业务的人

理解了 Loop 和 Harness，就能理解 2026 年为什么到处都在招 FDE（Forward Deployed Engineer，前置部署工程师）。

OpenAI、Anthropic、Google、EY、德勤都在大量招聘这个职位。他们做的事是：嵌入到客户的业务团队里，在真实的生产环境里把 Agent 跑起来——不是演示，是真正落地，交出可以衡量的结果。

这个人需要同时懂三件事：

Loop 工程——循环怎么设计，停止条件怎么定，上下文怎么管。

Harness 工程——运行底座怎么建，工具怎么设计，验证机制怎么搭，出了错怎么恢复。

评估工程——怎么知道 Agent 变好了还是变坏了。没有评估，改了 Harness 之后哪里退化了你不知道，换了模型之后哪类任务变差了你也不知道。2026 年 FDE 招聘里出现频率最高的词，就是 Eval Engineering。

还有一件事是纯技术之外的：业务判断——哪些决策该让 Agent 做，哪些必须留给人。这不是工程问题，是判断问题。Loop 再稳、Harness 再完善，如果把不该自动化的决策交给了 Agent，结果同样会出问题。

Loop 工程、Harness 工程、FDE——不是三个独立的概念，是同一件事从底层到落地的完整链条

Loop 是 Agent 的心脏——它决定 Agent 怎么思考和行动。

Harness 是 Agent 的骨架——它决定 Agent 在生产环境里能不能稳定运行。

FDE 是把这个 Agent 装进真实业务的人——它决定 Agent 能不能真正产生业务价值。

这三个词同时在 2026 年流行，背后是同一个原因：AI 正在从”聊天工具”变成”工作单元”。

当 Agent 只是问答助手，你不需要这些——一次对话，一次回答，结束。当 Agent 开始承担真实任务，需要连续运行、出错恢复、结果验证、成本控制，Loop 工程、Harness 工程、FDE 就成了绕不过去的事。

---

内容效果不满意？点此反馈