Agent 架构怎么从零设计?

这道题其实在问一个决策循环怎么搭起来。我会把它拆成四层：感知、规划、执行、记忆，核心是让[[Agent]]在环境里感知后，规划怎么行动，执行工具，再把结果记下来影响下一步。

先说感知层，这里我直接对接[[多模态]]输入，比如文本、图片、语音，但真正重要的不是怎么接，而是怎么把用户意图拆成可执行的任务。举个例子，用户说“帮我查一下这笔退款为什么还没到账”，感知层要理解这是查询退款状态，而不是投诉客服，所以意图分类和实体抽取是关键。

规划层是整个Agent的脑子。我用 [[ReAct]] 作为默认策略，让模型在思考、行动、观察之间循环，每一步都输出推理轨迹再选工具，这样比纯[[Chain-of-Thought]]|CoT更可控。如果任务特别复杂，比如要跨系统查订单、库存、物流，我会启用 [[Tree-of-Thoughts]] 多路径并行探索，用模型自己打分剪枝。但ToT成本高，只有简单规划走不通时才触发，平时ReAct就够了。

执行层就是工具调用。我采用OpenAI风格的[[Function Calling]]，工具用JSON Schema描述，关键不在模型能不能理解，而在工具描述本身就是Prompt工程。比如一个查订单的工具，你得写明“当用户提供订单号时调用，订单号格式是xxx，常见错误是传了手机号”，不然模型会瞎猜。这里有个坑：工具多了容易混淆，我会按场景分组，比如客服场景只暴露退款、物流、商品查询三类工具，减少选择噪音。

记忆层我分三级。工作记忆就是当前对话上下文，直接放[[Sliding Window]]|滑动窗口里。短期记忆存最近N轮摘要，保证会话连贯性。长期记忆用[[Vector Database]]存用户偏好和领域知识，比如某个用户之前投诉过发货慢，下次再问类似问题，Agent能主动规避相关推荐。这里前提是向量检索质量要够，不然召回一堆无关的反而干扰。

落地时最关键的取舍是“人在环路”。我不会追求完全自主，反而会在关键决策点加人工确认，比如退款金额超过阈值或者要修改订单状态时，先暂停等审核。这不是技术限制，而是安全性和可控性的平衡。如果上线，我会特别关注失败时的回退逻辑：执行后强制验证结果是否回答了原始问题，失败最多重规划三次，三次还不行就转人工。常见失败场景是模型把工具调用参数搞错，比如查物流时传了订单号而不是运单号，所以工具描述里必须写清楚参数校验规则。

另外，规划层还可以引入 [[Self-Refine]] 让模型自己反思结果质量，但代价是延迟翻倍，所以在实时性要求高的场景我会慎用，比如客服对话里用户等不了十秒才回复。

所以整体上，我会把Agent看成一套带安全阀的决策循环，感知要准，规划要稳，工具要描述清楚，记忆要分层。更倾向。