当 Loop 不再是内核：Coding Agent 真正难的地方

两三年前,做一个 agent 的"内核"是一件能说清楚的事：ReAct 循环、任务拆分、memory、plan、tool calling，拼好就能跑。今天这套东西已经商品化了。它不是过时了，是它迁移了位置也就是说它沉进了模型本身。

理解这次迁移,比追逐任何一个新框架都重要。

能力的边界，由"可验证性"画出来的

前沿实验室现在用 RLVR(基于可验证奖励的强化学习)把 agentic 行为直接训进模型：多轮工具调用、自我纠错、中途重新规划。一种能力能不能被训进模型,取决于它的结果能不能被廉价地验证。

强化学习需要一个 verifier 来判断“这一步做得好不好”。凡是结果可以被一个程序自动判定对错的领域，模型就能在上面做大规模自我博弈,把能力内化。如果结果模糊、需要人来判断好坏的领域,这条路就很难了。

coding agent 先成熟并不是偶然。编译器和测试套件,就是一个免费的、客观的、永不疲倦的 verifier。代码的对错恰好落在机器可判定。我觉得 agent 的扩散顺序很清楚了：任何"数字动作 + 可校验结果"的领域会被依次攻克，而反馈一旦变模糊(比如 browser agent、研究类任务),难度就很大。

大模型擅长的，往往是那些容易验证对错的领域。

Harness 变薄，不是因为事情变少了

把推理和规划交给模型之后，外层的 harness 肉眼可见地变薄了。其实去看 Claude Code 这类工具的内部，会发现它的 loop 简单得近乎朴素。很容易得出一个错误结论：做 agent 这件事正在变简单。

实则不然。这里可以说是一种复杂度守恒：复杂度没有被消灭，它从循环逻辑里流了出来，重新沉淀到三个地方，system prompt、工具设计、context 管理。loop 的代码行数或许下降了,可是把一个 agent 做好所需要的判断力,一点没少。

如果继续在 loop 上发力，把 plan 模块打磨得更精巧、把状态机写得更工整，这些收益其实在递减，因为那块地正在被模型层吞掉。真正的杠杆，在模型接管不了的地方。

模型唯一无法替你做的事:决定它能看见什么

一个语言模型,无论多强,有一个根本的局限：它只能对它上下文里的东西做出反应。它没有眼睛 没有记忆，没有对外部世界的独立访问。它的整个"世界",就是我们喂进上下文的那些 token。

塑造模型的"世界"，它每做一个动作之后，看见的是什么。

SWE-agent 那篇论文提出过一个概念，叫 ACI(agent-computer interface)，agent 的智能表现，不只取决于模型本身，同样取决于它的动作会得到什么样的反馈。一个工具报错时，它返回的不是"日志",而是模型的下一条 prompt，是给它一段无意义的栈，还是给它一条能据以纠正的线索,直接决定了它接下来会不会卡死。**设计工具,其实是在设计模型所能感知的那个现实。**这比设计循环要根本得多。

对抗"遗忘"，管理那段会随时间腐烂的记忆。

上下文一长，中间的信息就会塌陷(所谓 lost-in-the-middle),会话会"腐烂"。context 工程的本质,不是把更多东西塞进去，是对一段有限且会衰减的注意力做主动的策展:什么该留、什么该压缩成摘要、什么该隔离到别处去处理、哪些"失败的痕迹"反而要刻意保留下来好让模型自我纠正。这是一项复杂的工程，而不是 prompt 技巧的集合。Manus 团队和 Anthropic 各有一篇 context engineering 的复盘,写得很好。

做 agent,正在从"编写控制逻辑"变成"为一个无法完全控制的智能体,设计它的感知与记忆"。编写控制逻辑是确定性编程，设计它的感知与记忆是更难、也是更有意思的那部分。

开始构建你自己的 Agent 吧

我做了一个开源的命令行 coding agent:codewright。
github 地址：https://github.com/Caldalis/codewright

它在设计上刻意押注"薄 loop、厚感知与记忆":引擎核心是一个朴素的流式循环,真正下功夫的地方都在外面——把工具的反馈设计成能引导模型恢复的形态、上下文逼近窗口时自动压缩、用只读的子 agent 隔离探索类任务以免污染主上下文、把验证过的经验蒸馏成可复用的 skill。模型层是 OpenAI-compatible 的,换个 base_url 就能在 GPT、DeepSeek、Qwen、本地 Ollama 之间切换。

欢迎大家去翻代码、提 issue 或 fork，也希望大家能点点 star:
https://github.com/Caldalis/codewright