Agent 不是会调工具就行规划、状态机和工作流编排怎么落地摘要很多团队做 Agent第一步刚学会接工具第二步就开始翻车。问题往往不在工具接少了而在系统根本没想清楚“这件事该怎么跑”。这就好比你给新员工配了电脑和权限却不告诉他公司流程。本文承接上篇的评测体系专门拆解 Agent 内部的执行骨架什么时候该用“麦当劳后厨”式的固定工作流什么时候该上“医院看病”式的状态机什么时候才真的需要放手让 Agent 自己当“包工头”做规划预计阅读时间10 分钟系列承接如果上一篇 Agent 怎么证明自己真的变好了评测、回放和 A-B 对比 解决的是“怎么证明它变强了”这一篇解决的就是另一个更致命的工程问题它在系统里到底该怎么跑才不会把自己绕晕。目录会调工具不等于系统就会干活三把斧头流水线、办事大厅与包工头第一把斧固定工作流麦当劳后厨流水线第二把斧状态机医院看病挂号流程第三把斧规划式 Agent全能包工头工程落地建议先把确定性吃满一个最小可跑的状态机代码骨架结语编排才是 Agent 的真骨架会调工具不等于系统就会干活我见过很多团队第一次做 Agent 的过程基本都出奇地一致。第一周大家兴致勃勃地把搜索 API、公司数据库、发邮件接口全接上了。在终端里跑通的那一刻看着大模型自己调用搜索查资料很容易产生一种错觉“哇它会自己干活了这事稳了。”到了第二周画风突变各种诡异的“翻车”接踵而至同一个客服请求昨天它先查知识库再回复今天它竟然先乱编了一通然后再去查库。走到中间某一步失败了它不知道重试直接原地死机或者干脆给用户返回一串报错代码。明明上一秒系统提示“已进入人工审批”下一秒大模型突然“戏瘾发作”自己把单子给批了往下走。明明只是查个天气模型非要先规划三步走慢得让人抓狂token 账单还高得离谱。这些问题的根源其实就一个系统缺乏明确的执行地图。工具只是“手”编排才是“路”。你给一个人再多工具如果不告诉他什么情况下走直路、什么情况下进岔路、什么情况下必须停下来等老板签字他照样会把事情做砸。这也是为什么 Anthropic 在其最新的架构文档中死磕workflow工作流和agent智能体的边界。这绝不是学术上的术语洁癖而是实打实的工程保命指南。今天我们不谈玄乎的“涌现”和“自进化”就聊最接地气的骨架设计如何管好你的 Agent别让它乱跑。三把斧头流水线、办事大厅与包工头如果把 Agent 执行任务的“自由度”排个序业内现在主流的玩法大概分这三档固定工作流Workflow步骤写死模型只负责在特定节点干苦力。状态机State Machine定义好一堆节点和状态系统根据手里的“状态票”决定下一步去哪。规划式 AgentPlanning Agent扔个目标过去模型自己拆解任务、排期、执行。这三者没有高低贵贱只有谁更匹配当前的业务。很多失败的业务最大的错就是把低不确定性的任务交给了高自由度的架构。明明一条流水线就能搞定的事非要让模型先开个会、再写个 PPT、最后才决定去按那个按钮。第一把斧固定工作流麦当劳后厨流水线如果任务的步骤是死的千万别犹豫直接上固定工作流。比喻一下这就是麦当劳后厨的炸薯条流水线。你不需要厨师有创意只需要他按部就班拿土豆 → 切条 → 下锅炸 3 分钟 → 捞起撒盐。要是你雇个米其林大厨大模型来干这个还让他自由发挥他可能今天给你炸个爱心形状明天心血来潮给你加点黑松露幻觉不仅贵还乱套。比如做一个“客服工单分类与回复”机器人最稳的做法是读取用户请求判断意图分类大模型介入查阅内部文档生成初步回复大模型介入发送给用户在这个流程里大模型只需要在“分类”和“生成”这两个节点打工其他环节全靠死代码if-else焊死。它的最大优势是极度可控、极度好测、成本极低。defhandle_ticket(user_message:str)-dict:intentclassify_intent(user_message)ifintent!password_reset:return{route:fallback}docssearch_docs(how to reset password)replydraft_reply(user_messageuser_message,docsdocs)return{route:send_reply,reply:reply}代码很土土就对了。只要单次串行流程够用就别整什么高并发多节点。但当你发现这套流程里分支越来越多、动不动要等人工审批满屏的if-else像个接满插头的劣质插线板时你就该拔掉它换第二把斧头了。第二把斧状态机医院看病挂号流程一旦任务不再是“一条路走到黑”状态机State Machine就成了救命稻草。这就像去医院看病。整个过程不是线性的而是状态的流转挂号处初始草稿状态医生初诊系统机器校验状态去验血挂起等待转入材料缺失状态拿报告回诊状态恢复回到机器校验节点开药走人审核已通过状态在这套逻辑里系统关心的不再是“下一步执行什么函数”而是当前手里捏着什么状态满足什么条件才能切换到下一个状态最经典的例子就是“报销审批 Agent”。用流水线做审批是做不下去的。当单子金额过大触发了挂起待人工审批状态时系统必须优雅地暂停把当前的数据存下来等第二天老板点完“同意”系统还要能优雅地恢复接着往下跑。这也是为什么 LangGraph 这类前沿框架核心全都在搞state node edge状态 节点 边。它把聊天的过程变成了在不同状态节点中跳跃的图结构。状态机的魅力在于不是函数在瞎跑而是状态在指挥。只要业务里出现“多分支”、“人工审批Human-in-the-loop”、“中断与恢复”、“审计留痕”闭着眼睛选状态机准没错。第三把斧规划式 Agent全能包工头再往上才是大家平时被各种科幻宣传洗脑的“完全自主 Agent”。这就像你雇了一个资深包工头。你只丢给他一句“帮我把这套毛坯房精装了预算 20 万。”至于他是先买水泥还是先买瓷砖遇到墙里有暗管怎么改方案全靠他自己定夺。在代码里这就是经典的ReAct推理与行动模式模型先思考大脑思考再决定调什么工具调用工具拿到结果后观察观察结果再决定下一步干嘛。这种模式极度强大能解决路径根本无法提前预判的开放性问题。比如让 Agent 去网上调研某个开源库的竞品分析它可能查到一半发现搜不到得临时换搜索词或者转头去爬 GitHub issue。但代价也是极其惨痛的成本刺客随便一跑就是几万 token 进去了。延迟爆炸用户等得黄花菜都凉了。犹如开盲盒你永远不知道它下一次运行会不会突然发癫把系统搞崩。所以把业务全交给规划式 Agent就等于把公司命运交给一个随时可能喝醉的包工头。工程落地建议先把确定性吃满这三把斧头看懂了落地时该怎么选教你一个极其势利的判断顺序步骤是死的吗如果是上流水线。把模型关进笼子里只让它做阅读理解和填空。需要暂停、恢复或人工介入吗如果需要上状态机。用明确的状态管理取代糊涂的对话历史。问题真的无解、只能走一步看一步吗只有被逼到这份上才放手让 Agent 自己去规划。核心心法就是先把确定性吃满再把不确定性留给模型。真正成熟的工业级 Agent从来不是单打独斗而是外围套着稳如老狗的状态机遇到复杂局部问题时再召唤一个小型规划式 Agent 解决单点问题。大框架死死管住小局部保留弹性。一个最小可跑的状态机代码骨架抛弃那些花里胡哨的 Prompt 补丁这里提供一个最纯粹的 Python 状态机骨架。它比流水线坚固又比规划式 Agent 听话。fromtypingimportLiteral,TypedDict# 1. 明确定义你拥有的状态classState(TypedDict):用户输入:str意图:str状态:Literal[已接收,需人工审核,可自动处理,已完成]回复:str# 2. 节点只做一件事改变状态defclassify(state:State)-dict:intentdetect_intent(state[用户输入])ifintentin{退款,账单风险}:return{意图:intent,状态:需人工审核}return{意图:intent,状态:可自动处理}defhuman_review(state:State)-dict:# 模拟暂停等待人工approvedget_human_decision(state)ifapproved:return{回复:已人工确认继续处理。,状态:已完成}return{回复:未通过审核任务结束。,状态:已完成}defauto_handle(state:State)-dict:replygenerate_reply(state[用户输入],state[意图])return{回复:reply,状态:已完成}# 3. 显式的路由用状态决定去向别让大模型瞎猜defroute(state:State)-str:ifstate[状态]需人工审核:return人工审核节点ifstate[状态]可自动处理:return自动处理节点return结束记住两个原则节点只干一件事路由逻辑靠代码而不是靠 Prompt。一旦这副骨架搭起来后续不管你怎么加重试、加人机协同都只是在骨架上长肉系统绝对不会垮。结语编排才是 Agent 的真骨架一个能真正在生产环境活下来的 Agent不是因为它接入了 100 个工具而是因为它知道什么时候该直走什么时候该转弯什么时候该停下来等老板签字。别再沉迷于让大模型帮你规划一切了。用死板的流程管住确定性用严谨的状态机管住分支只把最难啃的骨头扔给大模型的聪明才智。这才是让你的 Agent 项目不烂尾的唯一出路。