我理解大模型 [[Agent]] 和普通 Chatbot 最大的区别，是它不只是回答问题，而是能围绕一个目标做规划、调用工具、观察结果，再决定下一步。典型架构可以概括成一个闭环：感知、规划、行动、观察、记忆，循环直到任务完成或触发停止条件。
感知模块负责把用户输入、环境状态、工具返回结果统一整理成系统能理解的状态。比如用户说“帮我看下这个订单为什么没退款”，系统不能只把这句话丢给模型，还要识别意图、抽取订单号、确认用户权限，并把这些变成结构化状态。
规划模块负责决定下一步做什么。简单任务可以一步完成，比如查一个天气；复杂任务要拆成子任务，比如先查订单状态，再查退款规则，再判断异常原因，最后组织回复。常见的 [[ReAct]] 模式就是边推理边行动：模型先给出下一步意图，再调用工具，拿到 observation 后继续推理。这里要注意，线上系统不能让模型无限循环，必须有最大步数、最大 token、最大耗时这些限制。
行动模块就是工具调用。工具一般通过 [[Function Calling]] 或类似机制暴露给模型，每个工具都有 name、description、parameters schema。模型生成调用请求后，框架负责解析、校验、鉴权、执行，再把结果作为 observation 返回。这里我会特别重视安全和稳定性，比如参数范围校验、工具权限分级、超时熔断、失败重试和审计日志。
记忆模块分几类。短期状态保存当前任务约束和已验证观察，不保存隐藏推理文本；长期记忆只写入经授权、可追溯且有有效期的用户偏好或业务事实，并保留纠错入口。向量库只是检索手段，不能把召回内容自动当成真值。
整个流程跑起来就是：用户目标进来，Agent 解析状态，规划下一步，调用工具，拿到反馈，更新状态和记忆，再进入下一轮规划。直到模型判断任务完成，或者系统发现超时、循环过多、工具失败率太高，触发降级或人工介入。
工程上我会强调两个点。第一个是工具尽量确定性，能用数据库、计算器、搜索 API，就不要让模型猜。第二个是可观测性，记录结构化决策摘要、action、observation、状态迁移、工具耗时和错误，不记录隐藏 Chain-of-Thought。这样才能区分规划、工具和上下文故障。
所以 Agent 的核心不是“让模型自由发挥”，而是给模型一个受控的决策闭环：它可以计划和行动，但每一步都被 schema、权限、超时、日志和停止条件约束住。
