如果让我设计一个具备自主决策和工具使用能力的 [[Agent]],我会用一个“受控闭环”架构。它不是让大模型自由发挥,而是由状态管理器串起感知、规划、记忆、行动和反馈,每一轮都更新状态,并且受权限、超时、步数和审计约束。
先看感知模块。它负责接收用户输入、工具返回、环境事件,做意图识别和信息抽取,形成结构化状态。比如用户说“帮我处理这个退款异常”,感知层要抽取订单号、用户身份、当前意图、缺失信息,并判断是否需要鉴权。这样下游模块拿到的是清晰状态,而不是一段原始自然语言。
规划模块负责决定下一步。简单任务可以直接映射到工具调用;复杂任务才交给 LLM planner 或 [[ReAct]] 做多步拆解。这里我会加一个原则:高风险业务流程不能完全让模型自由规划,比如退款、发券、改订单,必须走状态机或审批流;模型可以负责解释和参数建议,但最终执行路径由系统约束。
记忆模块分短期和长期。短期记忆保存当前任务上下文、已完成步骤、工具 observation;长期记忆保存用户偏好、历史工单、领域知识和工具经验。长期记忆可以用[[向量库]]、关系库或图数据库,但写入时要做重要性评分和去重,不然越存越乱。读取时也要带权限和时间过滤,避免拿到过期或无权访问的信息。
行动模块负责工具调用。每个工具都要有 schema、权限等级、超时配置、是否有副作用、是否可重试。模型生成 tool call 后,系统先做参数校验和权限检查,再执行工具。对于写操作,比如发起退款、发送通知、修改配置,要支持 dry-run、人工确认或二次授权。工具返回结果后,要转换成标准 observation,回到状态管理器。
反馈模块负责判断任务是否完成,以及是否需要重试、换工具、请求用户补充信息或转人工。比如工具超时,可以重试一次;参数缺失,就问用户;连续多轮失败,就停止自动执行,避免 Agent 死循环。
[[RAG]] 在这个架构里可以作为一种工具,也可以作为长期记忆的一部分。规划模块在需要外部知识时调用 knowledge_retrieval,拿到资料后再决定是否继续调用业务工具。这样比每次对话都强制检索更灵活,也能减少无意义调用。
我认为这个系统的设计依据有三点:模块化,方便每层独立优化;反馈驱动,让每次工具执行都能改变下一步决策;受控自治,让 Agent 有决策能力,但不越过业务和安全边界。
这里有个高级问题:如果长期记忆、RAG 文档和实时工具结果互相冲突,应该信谁?我的做法是按来源可信度和时效性排序:实时业务系统优先,其次是有版本的知识库,再其次是历史记忆;冲突无法解决时,让模型明确提示不确定,而不是强行合并。