Agent 是一套运行系统

如果说 LLM 不是 Agent，那 agent 到底是什么？

可以先把 agent 理解成一套运行系统。

这套系统把模型放在中间，但不把所有责任都推给模型。模型负责根据当前输入生成下一步判断、文本或结构化意图；模型外面的 runtime 负责组织材料、调用工具、检查权限、记录状态、处理失败、决定什么时候继续，什么时候停下来。

一个粗略公式是：

Agent = Model + Context Management + Tools + Memory + Runtime + Governance + Verification

这里的重点不是公式本身，而是边界。

Model 负责语义判断。它读当前 context，理解用户目标，生成下一步。

Context Management 负责让模型这一轮看到合适的材料。它要决定历史、摘要、检索结果、工具输出、memory、skill、系统约束哪些进入当前轮，哪些留在外面。

Tools 负责连接外部世界。没有工具时，模型只能说话。接上工具之后，系统才能读文件、查资料、跑命令、发消息、改代码、调用 API。

Memory 负责保存不在当前窗口里的状态、偏好、经验和知识。它不是模型天然记住的东西，而是外部系统在合适的时候写入、检索、过期和注入。

Runtime 负责跑循环。它接收用户目标，组装 context，调用模型，解析模型输出，执行工具，拿回 observation，再进入下一轮。

Governance 负责边界。哪些资料能看，哪些工具能用，哪些动作要审批，哪些信息不能进入当前上下文，这些都不应该只靠模型自觉。

Verification 负责检查结果。测试有没有过，证据是否支持结论，动作是否真的完成，风险是否还没处理，什么时候需要人类 review。

把这些东西分开以后，很多产品问题会变得更可分析。

比如“agent 不稳定”，可能不是一个问题，而是几个不同层的问题：

- 模型判断错了

- context 里缺关键材料

- tool schema 不清楚

- runtime 没有校验参数

- memory 召回了过期信息

- 权限边界太松

- 缺少验证步骤

如果只把 agent 当成“一个更会聊天的模型”，这些问题就会混在一起，最后只能说“模型不够聪明”。

但如果把 agent 当成运行系统，就可以逐层调试。

模型是否看到了正确材料？工具调用是否结构化？权限是在 runtime 硬拦截，还是只写在 prompt 里？失败之后有没有重试策略？长任务中间有没有 checkpoint？最终结果有没有证据链？

这也是 agent engineering 和普通 prompt engineering 的区别。prompt 很重要，但它只是系统的一部分。真正能持续做事的 agent，需要一个可靠的运行底座来承载模型的判断。

一个简单的 agent loop 可以写成：

goal -> assemble context -> call model -> parse intent -> execute tool -> observe -> verify -> next step

这条 loop 里，模型只占其中一步。其它步骤看起来没有那么神秘，但它们决定了 agent 能不能从“会回答”变成“能做事”。