Agent 系统最容易让人兴奋，也最容易让人失焦。
你可以给它接聊天软件，可以让它调用浏览器，可以让它操作文件，可以让它长期记忆，可以让它定时执行任务，也可以让它在多个设备之间流转。每一项都很有吸引力，但如果一开始就从这些能力切入，很快会遇到一个问题：系统看起来像 Agent，内核却不像。
所以从头搭建 Agent 的第一步，不是接更多工具，也不是做更漂亮的界面，而是想清楚最小闭环。
输入 -> 理解上下文 -> 决策 -> 行动 -> 观察结果 -> 继续决策或输出
这是 Agent 和普通 Chatbot 最关键的区别。Chatbot 通常是“输入问题，输出答案”；Agent 则多了一层行动循环。它不只是生成文本，还要能判断什么时候需要行动、行动后如何吸收结果，以及如何把这次行动沉淀到之后的上下文里。
为什么先看架构，而不是先写功能
很多 Agent 项目一开始会从工具列表出发：
- 要不要支持终端？
- 要不要支持浏览器？
- 要不要支持 Slack？
- 要不要支持长期记忆？
- 要不要支持多 Agent？
这些问题都重要，但它们不是第一性问题。真正应该先问的是：
这个系统里，谁负责入口？谁负责上下文？谁负责决策？谁负责执行？谁负责记忆？谁负责安全边界？
如果这些边界没有想清楚，功能越多，系统越难改。工具会侵入模型层，入口会侵入状态层，记忆会变成一堆临时 prompt，安全策略会散落在各种条件判断里。
一个可长期演进的 Agent 系统，必须先有清晰的层次。
OpenClaw 给我的启发：Gateway 是一种架构重心
OpenClaw 的思路更偏 gateway-first。
它关心的不是单个对话窗口，而是一个长期运行的入口控制面。不同消息渠道、设备节点、控制 UI、远程连接，都会先进入 Gateway。Gateway 再负责会话、路由、通道连接、状态同步和事件分发。
这个思路很适合做“个人 AI 操作系统”一类产品。因为当 Agent 不只存在于一个 CLI，而是存在于 Telegram、Slack、手机、桌面、WebChat、自动化任务里时，真正复杂的地方不只是模型调用，而是入口和状态的一致性。
OpenClaw 的启发是：如果你的目标是多入口、多设备、多通道，Gateway 不是外围组件，而是核心架构层。
Hermes 给我的启发：Agent Core 是另一种架构重心
Hermes 的思路更偏 agent-core-first。
它把 CLI、API、消息网关、批处理、IDE adapter 等入口都看成外围。真正的中心是一个稳定的 Agent Core。这个 Core 负责上下文构造、模型选择、工具调度、会话压缩、持久化记忆和回调。
这个思路很适合做“长期进化的智能体”。因为入口可以很多，工具也可以很多，但它们最终都应该围绕同一个决策循环运转。
Hermes 的启发是：如果你的目标是让 Agent 变得可靠、可记忆、可扩展，就要把 Agent Loop 做成真正的内核，而不是散落在各个入口里的临时代码。
两种路线背后的共同核心
OpenClaw 和 Hermes 的架构重心不同，但它们共享一个底层事实：Agent 不是一个模型 API wrapper。
一个 Agent 至少需要几层：
- 入口层
用户从哪里进入系统。可以是 CLI、TUI、Web、移动端、Slack、Telegram，也可以是定时任务。 - 会话层
系统如何识别“这是哪一次对话”“属于哪个用户”“属于哪个 workspace”“应该继承哪些历史”。 - 上下文层
每次调用模型前，应该放入哪些信息：当前消息、历史摘要、长期记忆、工具说明、系统人格、项目约束。 - 决策层
模型不只是回答问题，还要决定是否调用工具、调用哪个工具、参数是什么、是否需要继续下一轮。 - 工具层
工具必须被注册、描述、授权和调度。工具不是散落的函数，而是 Agent 能力边界的一部分。 - 记忆层
会话历史和长期记忆需要分开。前者记录发生了什么，后者记录未来仍然有价值的事实。 - 安全层
任何能执行命令、读写文件、联网或调用外部服务的 Agent，都必须有明确的安全边界。
第一版不一定要把每一层都做完整，但必须承认它们的存在。否则系统会在第二次扩展时开始变形。
最小闭环应该长什么样
我认为从零搭建 Agent，最小闭环应该是：
用户输入
-> 读取会话和记忆
-> 构造上下文
-> 调用模型
-> 判断是否需要工具
-> 执行工具
-> 记录观察结果
-> 再次调用模型或输出最终答案
-> 持久化这次过程
这个闭环里最重要的是“观察结果再进入决策”。如果工具只是一个外部函数，调用完就结束，那它还不是完整 Agent Loop。真正的 Agent 需要把行动后的结果带回上下文，让模型基于新状态继续判断。
这也是为什么我不认为“接一个 LLM API，再写几个函数”就等于 Agent。Agent 的核心不是工具数量，而是循环结构。
第一版应该克制
做 Agent 系统很容易过早复杂化。
一开始就做多 Agent，会把问题放大。一开始就做插件市场，会把边界放大。一开始就做复杂沙箱，会把工程成本放大。一开始就做十几个入口，会把状态同步问题放大。
更好的顺序是：
- 先做一个稳定 Agent Loop
- 再做可替换的模型 Provider
- 再做统一 Tool Registry
- 再做持久化 Memory
- 再增加更多入口
- 再做权限、安全、沙箱和自动化
这个顺序不是因为后面的东西不重要，而是因为它们都依赖前面的边界。
我对第一版 Agent 的判断标准
一个最小 Agent 原型，不需要很强，但应该具备几个性质：
- 可以不用真实模型也能测试主链路
- 可以替换模型 Provider
- 工具调用不写死在 Agent Loop 里
- 会话历史和长期记忆有明确区分
- CLI、TUI、Gateway 等入口可以复用同一个 Agent Core
- 每次行动都可以被记录和回放
- 安全策略有预留位置，而不是事后补丁
如果这些性质成立，系统就有继续长大的空间。反过来，如果第一版只有一个巨大脚本，哪怕功能很多，也会很快进入维护债务。
这一篇的结论
从头搭建 Agent，第一步不是追求“像一个完整产品”，而是先把内核想清楚。
OpenClaw 提醒我们：多入口、多通道、多设备场景下，Gateway 会成为架构重心。
Hermes 提醒我们：长期记忆、工具调度、上下文管理场景下，Agent Core 会成为架构重心。
而无论走哪条路线，最小闭环都绕不开：
上下文 -> 决策 -> 行动 -> 观察 -> 再决策
下一篇再进入更具体的问题：工具调用应该如何设计。尤其是，为什么工具不应该只是几个随手调用的函数，而应该成为 Agent 系统里的正式协议。
Discussion