这次我们来看一个讨论度很高的话题Agent 系统到底应该怎么搭。很多人第一次接触智能体开发看到网上又是 LangGraph、又是 ReAct、又是多智能体编排很容易被框架和名词带偏。其实一篇文章《The three ways people build AI agent systems》已经把这个问题讲得很清楚不管产品形态多复杂绝大多数 Agent 系统都落在三种构建方式里——状态机、规划型智能体、涌现型学习系统。这篇文章不推荐具体框架也不写“最强提示词”而是把这三种方式的可控性、灵活性、成本和适用阶段拆开对比并给出每个方式可以落地的代码骨架、测试方法和排查清单。如果你是刚准备做 Agent 应用、要选技术路线或者已经在迭代 Agent 但经常出现“模型乱跑、任务不稳、费用失控”的问题这篇内容可以直接收藏。先给结论状态机适合流程固定、要求高可控的场景规划型智能体适合任务开放、需要动态决策的场景涌现型学习系统适合在某个具体任务上投入大量训练资源、追求更高智能上限的场景。三者不是替代关系绝大多数生产系统最终都是先搭状态机主干再用规划型节点处理分支最后视情况对高频错误点做训练优化。1. 三种 AI Agent 构建方式速览维度状态机State Machine规划型智能体Planning Agent涌现型学习系统Emergent Learning核心思想先定义状态和转移条件系统按固定流程执行LLM 每一步自行决策该直接回答还是调用工具用训练与环境反馈让能力“涌现”不把每一步写死灵活度低流程之外的请求容易卡住高可以处理开放式任务最高可能发展出训练时没有明确设计的策略可控性与可解释性高每个状态都可见、可审计中模型行为需要日志和限制兜底低行为由策略决定难以精确解释开发成本低到中主要在流程设计中需要处理循环、上下文、工具调用高需要数据、奖励设计、训练资源典型例子客服工单流程、审批流、RAG 管线ReAct 循环、Plan-and-Execute、Orchestrator-Worker强化学习训练的网页操作模型、代码生成模型、某些推理模型适合阶段已验证的确定性流程任务边界较宽但可加护栏的阶段产品模式稳定、需要持续提升模型能力的阶段三种方式的核心差别一句话就能说清状态机把流程写死让系统照着执行规划型智能体把流程选择权交给模型涌现型学习系统干脆把“如何决策”本身变成训练目标。2. 方式一状态机State Machine2.1 状态机解决什么问题状态机是最接近传统软件工程的实现方式。它把一个复杂任务拆成明确的状态每个状态有确定的输入、动作和转移条件。用户请求进来后系统根据当前状态决定下一步而不是每次都让模型自由发挥。这种方式最大的价值是可控。状态是有限的转移条件是枚举的测试时可以把每个状态都覆盖到。出了线上问题可以直接从日志里还原用户走到哪个状态、卡在哪个转移条件上排查成本远低于“让模型解释自己为什么这么做”。从生产实践看绝大多数 RAG 问答、客服工单、订单查询、审批流、内容审核流本质都是状态机。即使今天许多产品打上了“AI Agent”标签内部仍然是一张由可控节点组成的图只是在部分节点用 LLM 做了分类、抽取、生成等工作。2.2 一个最小状态机示例下面用伪代码演示一个带路由的流程先判断用户意图再进入不同处理节点最后汇总输出。from typing import TypedDict, Literal class AgentState(TypedDict): user_query: str intent: str tool_result: str final_answer: str def classify_intent(state: AgentState) - AgentState: # 实际项目中可用 LLM 分类也可用规则先做一层过滤 query state[user_query] if 订单 in query or 物流 in query: state[intent] order elif 退货 in query or 退款 in query: state[intent] after_sale else: state[intent] general return state def route_by_intent(state: AgentState) - str: # 返回下一个状态名 return state[intent] _handler def order_handler(state: AgentState) - AgentState: # 调用订单查询工具结果写入 state state[tool_result] query_order_api(state[user_query]) state[final_answer] build_answer(state[tool_result]) return state def after_sale_handler(state: AgentState) - AgentState: state[final_answer] 已记录售后诉求转人工处理 return state def general_handler(state: AgentState) - AgentState: # 无匹配流程时进入兜底节点 state[final_answer] call_llm_general_chat(state[user_query]) return state def run_state_machine(query: str) - str: state AgentState(user_queryquery, intent, tool_result, final_answer) state classify_intent(state) next_state route_by_intent(state) # 状态转移表intent - handler handlers { order_handler: order_handler, after_sale_handler: after_sale_handler, general_handler: general_handler, } state handlers[next_state](state) return state[final_answer]这个示例的意图分类简单到可以直接匹配关键词但在真实系统中classify 节点完全可以换成 LLM 调用。关键点是状态机的“决策点”可以交给 LLM但决策之后能进入哪些分支、每个分支做什么仍然由开发者在图里定义。2.3 状态机的优点与局限优点是确定性强、可测试、成本可控。每个节点消耗的 token 基本稳定不会出现一次任务跑三十轮工具调用的极端情况。对金融、政务、企业服务这类需要留痕和审计的场景状态机是最稳妥的起步方案。局限则是面对“未定义流程”时很脆弱。用户需求只要跳出预设状态状态机就只能送回兜底节点或转人工谈不上灵活应变。因此状态机适合边界清晰、流程变化不频繁的业务这也是为什么成熟的 Agent 系统很少只用状态机而是在其中嵌入规划型节点。3. 方式二规划型智能体Planning Agent3.1 规划型智能体的核心循环规划型智能体的思路与状态机相反不预设完整流程而是由 LLM 在每个步骤自行决定“下一步做什么”。模型可以选择直接回答也可以选择调用某个工具把工具返回结果放回上下文继续推理直到给出最终答案。常见的实现形态包括 ReAct 循环、Plan-and-Execute先生成计划再逐步执行、以及多智能体编排中的 Orchestrator-Worker 模式。在这些形态里模型面对的不是有限的固定状态而是一组工具和一个任务目标。用户请求 - 模型决策直接回答 or 调用工具 - 调用工具并返回结果 - 结果追加到对话上下文 - 重复决策 - 模型给出最终答案3.2 带函数调用的 Agent 循环示例下面是一个示意性的 Agent 循环结构。实际项目中需要替换成你所使用的模型提供商的 API并补全工具定义、错误处理与日志。def run_agent(query: str, llm, tools, max_steps10): # 维护对话消息列表工具结果不断追加进来 messages [{role: user, content: query}] for step in range(max_steps): response llm.chat( messagesmessages, tools[t.to_schema() for t in tools], # 工具以 JSON Schema 形式给到模型 tool_choiceauto, ) # 模型没有请求调用工具说明它认为可以给出最终答案 if not response.tool_calls: return response.content # 依次执行模型要求调用的工具 for tool_call in response.tool_calls: name tool_call.function.name arguments tool_call.function.arguments tool_result run_tool(tools, name, arguments) # 工具结果作为一条消息放回对话 messages.append({ role: tool, tool_call_id: tool_call.id, content: tool_result, }) raise TimeoutError(f超过最大步数 {max_steps}任务未收敛)需要特别注意这里的response.tool_calls、tool_call.id、message 组合方式取决于你使用的模型和 SDK 版本。不同版本对函数调用 API 的字段定义有差异实操时先打印一次完整响应结构确认字段后再写循环能省去大量调试时间。3.3 单智能体还是多智能体编排规划型智能体又可以细分成单智能体与多智能体。单智能体让一个模型处理全部任务自主决定调用什么工具结构简单但上下文容易被无关内容撑爆。多智能体编排则引入一个 Orchestrator规划者或路由器由它决定把任务交给哪个擅长特定领域的子 Agent。Orchestrator-Worker 模式适合任务类别跨度大的系统。例如一个企业助手既要做绩效考核汇总又要查项目排期还可能处理报销规则让单 Agent 维护所有工具描述和领域知识既浪费 token也容易让模型选错工具。拆成子 Agent 后每个 Worker 只维护自己负责领域的工具与提示质量会稳定得多。但多智能体不是银弹。子 Agent 之间的通信会重复消耗上下文排错链路变长任何一个子 Agent 的不稳定都会传导到最终结果。从我的经验看团队对单 Agent 行为还没有足够把握之前不建议盲目上多 Agent。先让单个 Agent 把工具调用跑稳再拆编排才是更稳的路径。3.4 规划型智能体的优点与局限优点是能处理开放式任务不需要为每种用户请求预设流程。缺点是行为不稳定一次任务可能只调用一次工具就结束另一次可能陷入三十轮循环模型可能编造不存在的工具参数也可能被工具返回的恶意内容带偏。这种不确定性的代价是额外的延迟、token 成本与安全问题。因此规划型智能体不是“放手让模型跑”而是要在外层加好步数上限、超时、工具白名单、人工确认和日志链路。模型负责动态决策工程负责把风险边界圈住。4. 方式三涌现型学习系统Emergent Learning Systems4.1 什么是涌现型智能体前两种方式都建立在“开发者为系统设计行为”的前提上第三种方式则完全不同不靠手写流程也不靠每一步的即时决策提示词而是通过大量训练与环境反馈让模型自己在任务中学会策略。这里的“涌现”指的是系统发展出了设计者没有明确编码的行为和能力例如自主检索信息、工具使用的顺序策略甚至对环境的试探行为。这种方法通常是强化学习路线。系统会有可交互的环境、定义清晰的奖励信号、以及不断更新的策略模型。模型不再是拿到任务后临时推测下一步而是从训练中沉淀出“这种任务应该怎么推进”的策略。# 示意一个强化学习训练循环不代表可以直接运行的代码 for update in range(total_updates): # 1. 与环境交互收集一批轨迹 trajectories [] for episode in range(batch_size): observation env.reset() done False while not done: action policy_model.sample_action(observation) observation, reward, done env.step(action) trajectories.append((observation, action, reward)) # 2. 用累计收益设计 loss更新策略 policy_model.update(trajectories) # 3. 定期用验证集评估成功率、完成任务所需步数、违规动作数 evaluate(policy_model, eval_env)这类训练需要环境、奖励、数据与算力不是普通应用团队“写几行代码”就能造出来的。更常见的路径是使用基座模型在目标任务数据上做监督微调再用强化学习或人工反馈把行为校正到目标方向。4.2 哪些现象属于“涌现”能力现在的推理模型和多模态模型中已经能看到这种训练结果的影子。模型在训练中学会的不只是“按话术回答”而是形成了一套类似规划的推理链条先分解问题、列出条件、分步推导、自我纠错。当推理被应用到代码生成、网页操作、工具选择这样的环境中时模型会展现出任务规划行为而这些行为没有被任何人显式编码成“如果遇到报错就重试”的规则。另一个典型方向是“可自我学习的 Agent”。比如用一个具备编程能力的模型去写新工具、调用新工具在解决新任务的过程中动态扩充自身能力库。这个过程一旦形成闭环系统的能力边界就不再受开发期预定义的工具清单限制这是第三种方式最有想象力的地方。4.3 涌现型系统的现实门槛把这种方法作为团队的第一选择并不现实。它需要明确的训练目标、标注或可自动计算的奖励、可供反复探索的安全环境以及训练与评测的长期投入。成本不只是 GPU而是数据、奖励信号和模型调优的时间。一个更务实的使用方式是把涌现式训练当作“流程和规划都稳定之后再做的升级”。先用状态机和规划型智能体把产品跑起来积累用户真实任务数据找到模型重复出错的环节再针对这些环节收集训练数据并微调让高频错误逐步消失。这样既享受了涌现训练带来的上限提升又不至于在产品验证期背上过重的训练成本。5. 三种方式选型对比与决策建议对比项状态机规划型智能体涌现型学习系统流程确定性强弱中到弱对线上问题排查友好度很高中依赖 trace 链路低token 成本稳定性稳定波动大训练成本高推理相对稳定迭代速度快改流程即可快但行为验证慢慢需要训练周期质量保障方式状态测试覆盖场景集 护栏 日志回归评测集 奖励设计最适用的团队阶段从 0 到 1 验证任务已跑通需要提上限产品模式固化后持续优化选型时可以按下面逻辑判断如果任务边界清晰、流程多年不变优先使用状态机。不要因为想用 Agent 就把简单流程改复杂。如果用户请求难以穷举、需要多个工具配合就在状态机主干上替换出规划型节点让模型决定分支。如果模型在某类高频任务上反复犯错、且人工修正成本已经很高再考虑收集数据做定向训练。如果你还处于验证想法的阶段不建议触碰强化学习训练。先用现成大模型加函数调用把产品价值验证清楚比训练一个自己的 Agent 模型重要得多。6. 实用混合构建路线6.1 先用状态机搭主干无论最终目标多宏大第一个可上线版本都建议采用状态机结构。把产品流程画成图入口、意图判断、各业务节点、失败分支、兜底分支。LLM 只在节点内部做抽取、分类、生成等各种非确定性操作节点之间的流转由代码控制。这一步的好处是收敛快、易上线。你可以用传统接口测试覆盖每个节点确保业务闭环先成立。6.2 把非确定分支替换为规划节点跑一段时间后你会看到哪些请求频繁走入兜底节点。对这部分请求建立单独的状态把节点实现换成规划型 Agent。这个 Agent 负责提出计划、调用工具、验证结果完成后回到主干状态。这种“主干状态机 分支规划器”的结构在客服、运维、知识库产品中非常常见。比如确认退款的流程仍然由状态机控制但用户问“我能不能退这笔订单”由一个自带订单查询、政策检索、金额计算的规划节点来处理。这样既保留主干的可控性也为开放式问题留出弹性。6.3 上线后再考虑训练优化当规划节点稳定后把每一轮失败任务都保存为样本。按失败原因分类工具调用格式错误、意图理解错误、结果筛选错误。针对占比最高的几类错误才值得投入微调或强化学习。否则优先通过改进工具描述、增加校验、优化检索结果来解决问题成本低很多。这条路线本质上是在做“工程能力换时间”的判断。状态机让你先可用规划型节点让你更好用定向训练让你更高能。每一步都建立在上一步的真实数据之上而不是一开始就赌一个全自动方案。7. 工程底座工具、记忆、状态与 API7.1 工具设计是先决条件规划型 Agent 的质量一半取决于模型另一半取决于工具层。工具描述要写清楚用途、参数含义、返回值格式和错误语义。模型不是“理解工具”而是理解工具的描述文本。描述含糊会导致模型传错参数甚至选错工具。推荐在工具入口和出口各加一层校验。入口校验参数必填项、取值范围尽早拒绝非法请求出口统一收敛成结构化的 JSON超过长度限制就截断摘要避免超大工具结果挤爆上下文。7.2 记忆的三种形态Agent 的记忆至少包含三层。第一层是当前会话上下文所有工具结果都要追加到对话消息中供模型继续推理。第二层是长期存储用向量库保存用户历史、知识库结果、任务总结需要时按相关度召回。第三层是任务执行记录也就是 Agent 每一步的日志它为排错、复现和评测提供素材。记忆的关键不是“记住了多少”而是“关注了什么”。长上下文不代表更聪明反而会引入噪音。设计记忆时优先考虑每轮开始前哪些历史信息值得重新放回上下文哪些信息应该被摘要压缩哪些信息必须保留但不需要进入模型上下文。这里的取舍直接决定 token 成本和结果质量。7.3 状态与流程的可观测性状态机中的状态定义要显式、可枚举禁止把流程路径藏在 LLM 提示词里。规划型 Agent 则要把每次模型请求、每个工具调用、每次分支选择都落到结构化日志中。推荐为每一次完整任务分配 trace_id这样线上出问题时可以从一条 trace 还原用户问题、模型决策、工具结果与最终回答的完整链路。8. 测试与评估怎么证明 Agent 真的可用Agent 系统的测试难度远高于传统功能测试因为同一条输入在不同轮次可能得到不同结果。建议建立以下四层测试。第一层是场景集测试。准备几十到几百条覆盖典型路径、边界情况、注入攻击样本的输入固定模型版本后自动化跑批统计成功率。场景集要随线上 badcase 持续补充。第二层是断言式单元测试。对状态机节点、工具函数、参数校验逻辑做传统单元测试这部分要求 100% 确定性通过。LLM 行为不稳定的部分不放进单元测试避免把测试做成“摇骰子”。第三层是结果评估。对 Agent 最终输出可以使用三类方法人工抽检、规则校验、用更强模型做 LLM-as-Judge。评估不仅看答案是否正确还要看中间过程是否合理是否调用了不必要工具、是否有越权动作、是否在信息不足时强行下结论。第四层是安全与压力测试。模拟工具返回恶意内容、超长内容、诱导模型越权的 prompt injection 场景验证系统是否会被带偏。建议把指标固定下来任务成功率、平均完成时长、平均调用步数、单任务 token 成本、工具错误率、最终答案引用率。没有这些指标讨论“Agent 好不好用”只能是经验之谈。指标含义建议观察方式任务成功率最终输出满足用户目标的占比按场景类别分组统计平均调用步数完成任务所需的工具/推理轮数波动大说明决策不稳定单任务 token 成本一次完整任务的输入输出总量与调用步数、上下文长度强相关工具错误率模型传参错误或调用了不该调的工具优先优化工具描述与校验无事调用率不需要工具却仍然调用工具的比例越高说明模型理解越差安全事件数越权、注入、泄露等事件次数单独建安全回流集9. 资源占用、成本与性能观察不同实现方式的成本曲线差异很大。状态机每次任务调用次数基本固定成本可预算。规划型 Agent 的成本主要取决于步数和上下文膨胀幅度。工具结果不断追加到 messages 中后几轮请求的输入 token 会越来越大这是 Agent 项目费用失控的最常见原因。控制成本可以从四个方向入手。第一设置硬性的最大步数、最大上下文长度与请求超时。第二对工具结果做截断、摘要和去重。第三为不同类型节点选择不同档位的模型意图分类、信息抽取可以用小模型复杂推理和大规模工具调度才用大模型。第四引入缓存对相同或相似的工具结果、检索结果复用避免重复计费。延迟方面规划型 Agent 每一次工具调用都要等一轮模型响应用户感受到的等待时间 模型单轮耗时 × 调用轮数。优化路径包括减少无效轮次、用并行工具调用替代串行、优先用小模型处理简单节点。上线前用“最坏输入”场景做压力测试而不是只测正常路径。10. 常见问题与排查方法问题现象可能原因排查方式解决方案Agent 一直循环调用工具不结束缺少步数限制、模型未能在工具结果中找到答案查看 trace 中每轮决策原因加 max_steps超时强制中断改进工具结果内容模型频繁传错工具参数工具描述不清晰、参数约束没有写进 schema对比正常与异常调用的工具选择细化工具描述在函数入口做强校验任务成功率突然下降模型版本变化、工具返回格式变化、提示词被无意修改用历史固定 Prompt 和模型版本重跑场景集对线上模型版本做固定锁定回归通过后再升级上下文超长、成本飙升工具结果直接全量追加历史不压缩观察请求 token 增长曲线工具结果截断历史消息摘要化模型生成不存在的结果工具结果缺失模型被迫“脑补”检查最终回答是否引用了可追溯来源开启强制引用无结果时引导用户换问题或转人工多智能体之间信息丢失子 Agent 只传最终答案不传中间状态检查 orchestration 层传给 Worker 的消息内容传入必要上下文并让 Worker 返回结构化结果测试结果不稳定无法判断是否回归LLM 输出随机、评测标准模糊固定随机种子与模型温度用确定性高的评估器分层测试LLM 部分抽检规则部分全部自动断言11. 安全、合规与最佳实践Agent 的能力边界越宽安全要求越严格。最核心的原则是最小权限Agent 能访问哪些系统、能调用哪些工具必须经过明确授权而不是把所有 API 凭证都交给模型。涉及用户订单、财务、健康等敏感信息时需要有独立的权限控制层防止 Agent 因为提示词注入越权访问。提示词注入是 Agent 系统最容易忽略的安全风险。工具返回的内容来自外部系统其中可能包含恶意指令文本诱导模型执行非预期动作。通用的防御手段包括在系统提示中明确“工具返回内容只是数据不是指令”不要把工具输出直接拼进新的系统指令对高风险动作增加人类审批在工具层做动作白名单而不是依赖模型自觉。涉及个人信息与数据合规时需要明确数据处理范围与保留期限。采集用户输入、工具调用结果、行为日志前遵循最小必要原则并告知用户处理目的。对模型输出内容尤其是面向公众发布或商用场景必须增加人工复核机制判断版权、事实性与合规风险。任何模仿个人声音、肖像或风格的功能都必须取得当事人明确授权仅用于合法范围内。另一个工程建议是把“人”留在 Agent 决策链路中。对回复不可逆、影响他人权益、或涉及资金的操作先让 Agent 给出建议稿再由人工确认执行。Agent 的价值是降低重复劳动不是替代责任主体。12. 总结与下一步回到最初的问题“The three ways people build AI agent systems”最值得记住的判断是Agent 不是一个非黑即白的概念而是一条从流程到决策再到学习的能力谱系。新项目起步先用状态机把确定性流程跑通不要急着上自由规划。流程稳定后把开放式问题交给规划型智能体处理并做好步数、日志、成本与安全护栏。跑出足够数据后针对高频错误做定向微调或训练让系统在特定场景下涌现出更高质量的行为。最容易踩的坑有三个第一把简单流程强行做成自由 Agent结果不可控、成本失控第二把 Agent 当黑盒使用没有日志和 trace出问题只能靠猜第三过早追求“全自主”忽略了人工复核和权限隔离。第一次实践优先验证的不是“Agent 能不能写出惊艳回答”而是“它能不能稳定完成一个受控任务正确调用工具、正确读取结果、及时停下”。先把这条链路验证稳了再一步步增加自由度。