如何让程序像人一样把大任务拆成小步骤调用外部工具获取信息并记住已经做过的事情最终给出可靠的答案一个“最小可用”的 Agent 并不需要庞大的模型或复杂的多智能体框架只需四个彼此协作的组件规划器Planner、工具执行器Tools、记忆机制Memory和主循环控制Main Loop。一、规划器Planner—— 决策的“大脑”规划器负责回答一个核心问题“根据当前已知信息下一步该做什么”它有两种实现模式可以根据场景切换 状态机模式轻量、确定、无需 LLM将任务分解为多个阶段每个阶段检查记忆中的特定标志然后决定调用哪个工具。例如对于一个“先计算后搜索”的任务状态机逻辑为# 检查记忆中的工具返回记录has_calcany(计算结果instr(msg)formsginmemoryifmsg[role]tool)has_searchany(AI Agentinstr(msg)formsginmemoryifmsg[role]tool)ifnothas_calc:# 阶段1执行计算return{tool_calls:[{function:{name:calculator,arguments:{expression:12*934-10}}}]}elifnothas_search:# 阶段2执行搜索return{tool_calls:[{function:{name:search_info,arguments:{query:AI Agent 发展现状与未来趋势}}}]}else:# 阶段3所有工具已完成生成最终回答return{content:综合所有结果……,tool_calls:[]}这种模式无需调用大模型速度快、成本低适用于流程固定的任务。 LLM 模式灵活、泛化、带工具描述当任务千变万化时我们让大模型本身充当规划器。只需在系统提示中附上可用工具的schema函数名、参数、用途并让模型输出结构化的tool_calls或最终回答。示例提示片段系统你是一个能调用工具的助手。可用工具calculator(expression)计算数学表达式search_info(query)搜索当前信息根据用户问题决定调用工具或直接回答并以 JSON 格式返回。LLM 会根据当前记忆对话历史自主决定调用哪个工具、调用几次甚至进行反思修正。两者对比✅ 表示优势⚖️ 表示权衡特性状态机模式LLM 模式决策依据硬编码规则模型推理执行速度✅ 极快较慢需 API 调用成本✅ 几乎为零每次规划需付费任务灵活性低需预定义流程✅ 高适应新任务可解释性✅ 决策路径清晰依赖模型解释对记忆的依赖仅检查特定字段✅ 全面理解上下文实际生产环境中两者常结合使用用状态机处理标准流程用 LLM 处理异常或复杂分支。二、工具执行器Tools—— 行动的“手脚”规划器决定调用哪个工具后必须有一个机制将工具名称映射到实际函数并执行它。最直接的方式是维护一个字典注册表TOOL_MAP{calculator:lambdaexpression:eval(expression),# 生产环境请用安全计算库search_info:lambdaquery:f根据搜索结果{query}—— 这里是模拟返回内容}# 在循环中执行forcallindecision[tool_calls]:func_namecall[function][name]argscall[function][arguments]resultTOOL_MAP[func_name](**args)# 将结果写入记忆见第三部分工具可以是任何外部能力计算器、搜索引擎、数据库查询、API 调用、代码解释器等。关键在于统一输入输出格式让规划器和记忆机制无感知地处理结果。三、记忆机制Memory—— 经验的“便签本”记忆是 Agent 的“工作区”它按时间顺序存储所有消息包括系统指令system定义角色和行为准则如“你是一个专业 AI 智能体……”。用户问题user原始任务。工具返回tool每次工具执行的结果通常包含工具名称和返回值。最终回答assistant规划器生成的输出。在 Python 中记忆就是一个列表memory[{role:system,content:你是一个专业AI智能体具备任务拆解、工具调用、反思修正能力。},{role:user,content:计算 12*934-10并介绍当前AI Agent的发展现状与未来趋势}]# 每次工具执行后追加memory.append({role:tool,content:f计算结果{result}})# 最终回答追加memory.append({role:assistant,content:final_answer})记忆的作用为规划器提供“已做之事”的上下文避免重复操作。在 LLM 模式下将完整记忆作为对话历史传入模型让模型理解全局。最终可将记忆持久化实现多轮对话或断点续接。四、主循环控制Main Loop—— 过程的“发动机”所有组件需要在一个循环中协同工作直到任务完成或超出步数限制。循环执行“规划 → 行动 → 观察”三步形成经典的ReActReason Act模式max_steps8forstepinrange(max_steps):# 1. 规划decisionplanner.plan(memory)# 状态机或 LLM# 2. 如果有最终回答结束循环ifdecision.get(content):final_answerdecision[content]memory.append({role:assistant,content:final_answer})break# 3. 否则执行工具调用行动forcallindecision.get(tool_calls,[]):func_namecall[function][name]argscall[function][arguments]resultTOOL_MAP[func_name](**args)# 4. 观察将结果写回记忆memory.append({role:tool,content:result})# 如果达到最大步数仍未完成可强制输出当前记忆或报错最大步数如 8 步是防止死循环的安全阀。当 Agent 误入重复调用时能主动退出并提示用户。五、交互流程决策工具调用执行结果决策最终回答上下文用户输入记忆系统规划器工具执行器输出结果MainLoop而主循环的每一步都遵循“规划→行动→观察”的闭环用户工具记忆规划器主循环用户工具记忆规划器主循环alt[工具调用][最终回答]传入当前记忆读取状态返回已有记录返回决策工具调用/最终回答执行工具返回结果写入工具结果观察下一轮规划写入最终回答输出结果六、一个完整示例计算 搜索以用户任务“计算 12*934-10并介绍当前 AI Agent 的发展现状与未来趋势”为例我们采用状态机模式步数上限为 8实际执行轨迹如下步骤阶段决策依据行动/观察1规划记忆中没有工具返回调用calculator参数12*934-101行动观察执行计算器得到 132将“计算结果132”写入记忆2规划记忆中有计算但无搜索调用search_info参数“AI Agent 发展…”2行动观察执行搜索返回一段描述将搜索返回内容写入记忆3规划计算和搜索都已存在生成综合回答包含数字结果和趋势概述3完成输出最终回答退出循环记忆追加 assistant 内容最终回答模拟计算结果132根据搜索AI Agent 正在从单一智能体向多智能体协作演进趋势是轻量化、可信化、行业化……综合以上本次计算结果为 132AI Agent 正从单智能体向多智能体协作演进趋势是轻量化、可信化、行业化。记忆最终状态共 5 条消息system你是一个专业AI智能体……user计算 12*934-10并介绍……toolcalculator计算结果132toolsearch_info根据搜索结果……assistant综合回答……七、总结与扩展一个最小可用的 Agent 架构其精髓在于“以记忆为纽带以规划为引擎以工具为手脚以循环为节拍”。这种设计具备三个显著优点可观测性每一步的决策、行动、观察都被记录便于调试和审计。可扩展性新增工具只需注册到TOOL_MAP调整规划器逻辑即可。成本可控状态机模式几乎不消耗模型调用LLM 模式仅在需要时启用。可以在最小架构之上叠加更多能力反思机制让规划器回顾历史步骤判断是否需要重新规划。多智能体协作规划器将任务分配给不同角色的子 Agent。流式输出在生成最终回答时逐字返回提升用户体验。
)
