AI Agent 认知架构详解 (Cognitive Architecture)

很多人第一次做 Agent，会把注意力几乎全部放在模型选型上：Claude 还是 GPT，长上下文还是快模型，参数大一点是不是就更聪明。做一阵子以后通常会发现，模型当然重要，但它只是系统的一部分。真正决定 Agent 能不能持续做事的，是整套认知架构有没有搭稳。

如果把 Agent 理解成一个“会推理、会调用工具、还能记住事情的软件系统”，那至少要把四个部分想清楚：Brain（大脑）、Memory（记忆）、Planning（规划） 和 Tools（工具）。

#1. 先别急着谈框架，先看这四块怎么配合

很多 Agent 图画出来都很像，但落地时差别很大。核心不在于图长什么样，而在于这几个模块之间有没有形成闭环：

• 大脑负责理解和决策
• 规划负责拆步骤和调整路线
• 记忆负责保存上下文和历史知识
• 工具负责真正和外部世界交互

少了任何一块，系统都会变得很别扭。

Lilian Weng 早期那篇关于 LLM Agent 的文章之所以影响很大，不是因为她给了一个“唯一标准图”，而是因为她把这些关键组件拆得很清楚：

#2. Brain（大脑）：不是万能执行器，而是决策中心

LLM 在 Agent 里最重要的工作，不是“替你把所有事情做完”，而是做判断：

• 用户到底要什么
• 当前信息够不够
• 下一步应该查资料、调工具，还是直接回答
• 工具结果回来后，是否需要改计划

所以我更喜欢把大脑理解成“决策层”，而不是 CPU 类比里的“算力中心”。因为很多执行动作最后都不是模型亲自做的，而是交给外部工具或子模块做。

#大脑最容易出问题的地方

如果系统设计不好，大脑层常见的问题会是：

• 看懂了用户意图，但不会拆任务
• 会拆任务，但不会根据 observation 修正
• 明明缺信息，却先给一个看似合理的答案
• 把工具调用结果和原始假设混在一起，最后越走越偏

这也是为什么高质量 Agent 往往不只是换个更强的模型，而是会给模型更清晰的职责边界和执行协议。

#选模型时更该看的，不只是“聪不聪明”

做 Agent 时，模型选择通常要同时看几件事：

• 指令遵循稳不稳
• 工具调用格式稳不稳
• 长上下文下会不会掉关键信息
• 成本和速度能不能支撑循环执行

复杂推理、代码修改、长流程任务，通常更依赖强一点的模型；而轻量路由、简单抽取、格式整理，完全可以交给便宜一些的模型。真正成熟的系统很少全流程只压一个模型。

#3. Memory（记忆）：没有记忆，Agent 很难像“持续协作”

如果 Agent 每次都从零开始，它顶多算一个会调用工具的聊天机器人。只要任务跨轮次、跨文件、跨会话，记忆就会变成刚需。

#A. 短期记忆

短期记忆最常见的载体还是上下文窗口、会话状态和摘要。

它主要解决的是当前任务的连续性，比如：

• 上一轮已经确认过哪些约束
• 当前任务做到哪一步了
• 哪些工具已经调用过，返回了什么

短期记忆的难点不在于“能不能存”，而在于“留哪些”。全部保留通常既贵又乱，最后模型反而抓不住重点。

#B. 长期记忆

长期记忆解决的是跨会话复用问题，比如：

• 团队知识库
• 历史决策
• 用户长期偏好
• 已验证过的解决方案

RAG 是常见方案，但不是唯一答案。向量库适合模糊检索；用户画像、权限、配置偏好这类明确事实，往往更适合结构化存储。

sequenceDiagram
    participant User
    participant Agent
    participant VectorDB
    
    User->>Agent: 提问: "上次会议关于 API 的结论是什么？"
    Agent->>VectorDB: 搜索相似向量 (Query Embedding)
    VectorDB-->>Agent: 返回相关会议记录片段 (Top K Chunks)
    Agent->>Agent: 注入 Context 并推理
    Agent-->>User: 回答: "上次会议决定..."

#4. Planning（规划）：让任务有顺序，也让失败能回头

复杂任务最怕的不是难，而是乱。

用户一句“帮我把这个项目里的登录问题修掉”，背后可能包含：

• 先定位相关代码
• 找到复现路径
• 决定修法
• 改代码
• 跑测试
• 检查是否引入回归

没有规划层时，模型很容易直接跳到“改代码”这一步。结果往往是改了，但没验证；或者修了表面问题，根因还在。

规划层最核心的价值是两件事：

• 把大目标拆成可执行的小步骤
• 在执行过程中根据新结果调整路线

这也是 CoT、ReAct、Reflexion 这些方法有意义的原因。重点不在名字，而在于它们都在解决一个问题：让 Agent 不要盲走。

#5. Tools（工具）：没有执行能力，规划再漂亮也只是纸上谈兵

工具层负责把模型的决策变成真实动作。

常见的工具大概分几类：

• 信息获取：搜索、数据库查询、知识库检索
• 文件与代码操作：读写文件、跑命令、查看 diff、执行测试
• 外部系统集成：GitHub、Notion、Jira、Slack
• 环境感知：浏览器、截图、日志、监控指标

这里最关键的不是“工具多”，而是：

• 调用边界清不清楚
• 参数 schema 稳不稳定
• 返回结果是不是足够结构化
• 工具有没有权限控制和失败处理

很多 Agent 之所以出问题，不是因为不会思考，而是工具层做得太随意，最后一调用就歪。

Function calling 和 MCP 这类协议，解决的就是“怎么让模型稳定地理解和使用工具”这个问题。

#架构图总结

graph TD
    User[用户指令] --> Brain[LLM (大脑)]
    
    subgraph Cognitive_Architecture ["认知架构"]
        Brain <--> Planning[规划模块<br/>(CoT, ReAct)]
        Brain <--> Memory[记忆模块<br/>(RAG, VectorDB)]
        Brain <--> Tools[工具模块<br/>(API, MCP)]
    end
    
    Tools --> Environment[外部环境<br/>(GitHub, Browser, DB)]
    Environment --> Observation[观察结果]
    Observation --> Brain

#小结

一个靠谱的 Agent，不是“模型很强”这么简单，而是这四层能不能配合起来：

1. Brain 负责判断。
2. Planning 负责安排顺序和回退。
3. Memory 负责延续上下文和复用经验。
4. Tools 负责和真实世界交互。

这四块如果只强一块，系统通常还是会别扭。真正稳定的 Agent，往往不是某一层特别炫，而是整条链路没有明显短板。