构建 AI 架构的正确方式
我以前认为，让我的 AI 助手变得更聪明，意味着在同一个循环中添加更多的工具。 这在一段时间内是有效的。 但后来，我的助手必须执行常规的用户任务，例如从聊天中继续任务、回答状态查询或记住工作流。
问题不在于我的助手可以调用多少工具，而在于它的架构。 旧的架构很简单：用户消息 -> 助手循环 -> 工具 -> 回答。 这对于演示来说没问题，但对于一个常驻助手（resident assistant）来说并不适用。
一个常驻助手需要知道一条消息是一个新任务、后续跟进还是取消操作。 它需要避免从另一个任务中抢占桌面控制权，并且无需使用旧的对话记录就能记住操作流程。
所以我不再把我的助手看作一个单一的 Agent，而是开始将其视为一个本地控制平面（local control plane）。 现在我的架构如下：
- Experience Plane（体验平面）：负责用户交互的入口
- Assistant Control Plane（助手控制平面）：决定任务类型
- Runtime Execution Plane（运行时执行平面）：进行编码工作的地方
- Proxy / Model Access Plane（代理/模型访问平面）：处理供应商相关工作
我还有一个 Observation Plane（观察平面）和 Memory / Policy Plane（记忆/策略平面）。 这些平面帮助我的助手保持理智并专注于其任务。
最大的改进在于让我的助手消费观察结果（observations）而不是原始日志（raw logs）。 这能帮助我的助手看到简洁的事实，例如“任务 X 正在等待审批”，而不是阅读冗长的对话记录。
我意识到，“记忆”并不等同于在 Prompt 中塞入更多的聊天历史。 对于我的助手来说，记忆是基于文件且具有作用域（scoped）的。 它可以存储一个工作流、一个事实或一个引用，并在需要时将其召回（recall）。
如果你正在围绕现有工具构建 Agent，你是在把所有东西都放在一个循环里，还是也开始拆分控制、执行、观察和记忆了？
Source: https://dev.to/codekingai/my-ai-assistant-needed-a-control-plane-not-a-bigger-loop-15aa Optional learning community: https://t.me/GyaanSetuAi