90%的Agent一上线就翻车：从对话到执行的四层架构拆解

AI领域的概念更新速度堪比短跑冲刺——从提示工程到循环工程，再到如今的Ontology和FDE，表面是技术迭代，内核却始终指向同一件事：让AI真正落地干活。过去两年行业比的是哪个模型分数更高，而现在竞争标准正悄悄换轨——谁能真正把活干完。

B站UP主梁老师在一期视频中用一个跨境电商退货退款的真实场景，把智能体落地拆解到可以动手的颗粒度。他给出的核心判断是：从「会聊天」到「能干活」，中间隔着的不是模型智商，而是一整套工程能力。而大多数团队只做了其中第一层，所以演示惊艳、上线翻车。

AI正在从「接口」变成「劳动力」

三条看似无关的行业动态，其实指向同一个方向。

向上，走进企业。韩国电信KT推出企业级智能体平台Agentic On，把AI接入企业现有数据和系统，处理文档审查、审批流转、系统录入这类多步骤自动化任务。向身边，走进硬件。Meta宣布将把个人智能体Muse接入其AR眼镜，用户无需掏手机，一句话即可唤醒，智能体还会根据用户正在看的内容执行任务。向下，走到算力底座。伯恩斯坦指出，智能体把一次问答扩展成了「规划—检索—工具调用—执行—检查」的完整过程，于是GPU推理负载、CPU需求、内存缓存、数据库和存储被同时拉动。Anthropic与相关厂商签下7年116亿美元、明确面向CPU工作负载的协议，正是算力需求向GPU之外扩散的信号。

三件事放在一起，结论只有一个：AI的形态正在从「接口」变成「劳动力」。

对话式AI与执行式Agent的本质区别

两者的区别不在模型，而在「谁承担办成的责任」。

对话式AI是这样一个循环：我问它答，我再决定下一步怎么做，责任始终在我身上，它的产出只是一段文字。执行式智能体是另一个循环：我把一件事交给它，它自己规划、调工具、执行、检查，发现不对就重试，最后交还给我一个已经完成的结果——责任转移到了系统身上。

智能体办一件事的真实过程是一个循环而非一次问答：理解目标 → 拆解规划 → 检索上下文 → 调用工具 → 执行动作 → 检查结果 → 不通过则重试或升级给人。这七个环节里，只有第一个和「聊天」有关，后面六个全是执行。这也解释了为什么智能体会同时拉动推理、缓存、数据库和存储——它在反复循环，而不是一次性生成。

难点的根源在于：对话可以模糊，执行必须精确。聊天答错了，用户笑一笑再问一次，成本几乎为零；执行动作做错了，钱已经打出去、工单已经关掉、数据库已经改了，成本是真金白银加上信任。梁老师由此强调一句话：智能体工程里90%的工作量，不是写提示词，而是设计出错时的退路。

落地第一步：用四个标准筛场景

落地的起点不是选模型，而是选场景。视频给出四条筛选标准：

• 高频：每天几百上千次，省下来的人力才看得见；
• 多步：至少三步以上且跨两个以上系统，否则一个脚本就够了；
• 可调：目标系统有接口，不是纯靠人敲键盘；
• 可兜底：万一错了能撤回，或有人能接住。

四条都打勾，才值得投入。

以跨境电商退货退款为例，用户只说了一句「我上周买的鞋穿了一次磨脚要退货退款」，智能体要真正办完这件事需要八步：读懂诉求 → 查订单系统 → 查物流系统 → 读售后政策 → 判断资格 → 调用退款接口 → 更新工单与客户记录 → 通知用户。这八步里只有第一步是对话，剩下七步全是执行。

能落地的智能体必须拆成四层

要把这八步真正跑起来，一个能落地的智能体至少要拆成四层：

• 大脑层：负责拆解任务、决定下一步；
• 工具层：把企业系统包装成有明确契约的可调用接口；
• 上下文与状态层：工单是有状态的长期任务，需要记忆和状态机，而非一次性对话；
• 治理层：负责权限、审批、审计和熔断。

梁老师观察到，大多数人只做了第一层（大脑层），结果就是「演示很惊艳，一上线就翻车」。

工具层的三条铁律

工具层最容易被低估，却最决定上线成败。给智能体一双手要守三条铁律：

第一，接口要窄。不要给它一个万能执行器，而要给它「查订单状态」这样的确定性工具，参数明确、结果可控、出错可归因。第二，动作要幂等。智能体会重试，而重试不应导致重复退款，每笔资金动作都要带幂等键，让重复调用是安全的。第三，权限要最小。查询可以放开，写操作和资金操作必须限额度、限范围、限频次。

一句话：工具的边界就是智能体的能力上限。

在退款接口的实现里，边界被三层约束收紧：幂等保证重试不重复退款；限额单笔不超过300元，超额走人工审批；调用参数中直接写入规则——金额大于300或置信度低于85就转人工。关键在于，这些约束不是写在提示词里求模型「自觉」，而是写在代码里强制生效。这正是把演示变成产品的分水岭。

**幂等性（Idempotency）**是分布式系统工程中的基础概念，指同一操作被执行一次和被执行多次，系统最终状态完全相同。在智能体场景中，由于网络超时、LLM重试或工具调用失败，同一个退款请求可能被发送多次。幂等键（Idempotency Key）的标准做法是在每次请求中携带一个唯一标识符（通常是UUID），服务端在首次处理后将结果缓存，后续相同幂等键的请求直接返回缓存结果而不重复执行。支付宝、Stripe等支付系统均将幂等键作为资金接口的强制参数。在智能体工程里，"动作要幂等"之所以被列为铁律，是因为LLM驱动的规划器天然具有不确定性，重试在架构层面几乎不可避免，一旦资金接口缺乏幂等保护，网络抖动就可能直接变成重复扣款或重复退款的资损事故。

**状态机（State Machine）**是描述对象在整个生命周期内所处状态及其转换规则的形式化模型，由"状态""事件"和"转换"三要素构成。以退货工单为例，其状态可能经历：已提交→资格审核中→待用户寄回→物流确认中→退款处理中→已完结/已驳回。每个状态只能通过特定事件触发合法转换，例如"已驳回"状态无法直接跳转到"退款处理中"。对话式AI无需感知这些状态——用户每次发消息，模型只需生成下一句回复即可。而执行式智能体必须在多步、跨时间的任务中始终知道"当前任务走到哪一步了""上次失败发生在哪个节点""下一步合法动作是什么"，这正是上下文与状态层存在的理由。缺少状态管理，智能体在任何一个中间步骤失败后都无法正确续跑，只能从头重来或彻底卡死。

门控：知道什么时候该停手

决定成败的真正问题，不是智能体「能不能做」，而是「这件事该不该它自己做」。

视频用金额与置信度两个维度给出分档规则：退款金额小、置信度高，可自动执行；金额小但置信度中等，交给另一个模型或规则做交叉复判；置信度很低，人工接管。而一旦金额超过300元，即使置信度很高也应做交叉复判；超过2000元则必须强制人工并叠加财务复核。

结论颇具启发性：自动化的成熟度，不体现在它多敢做，而体现在它知道什么时候该停手。

这里的置信度并非模型输出的softmax概率，而是一个业务层自定义的综合评分，通常由多个信号加权得出：意图识别的匹配度、关键槽位（订单号、金额、原因）的提取完整性、政策规则命中的明确程度，以及历史相似案例的处理一致性等。置信度阈值的设定本质上是一个风险收益权衡：阈值过高，大量可自动处理的简单工单被打回人工，效率增益有限；阈值过低，模型在语义模糊或边缘案例上强行自动执行，错误率随之攀升。实践中建议通过影子模式收集真实数据，用ROC曲线分析不同阈值下的自动化率与错误率，再结合业务可接受的错误代价确定最终阈值，而非拍脑袋设定一个固定数字。

上线后怎么评估：别只看一个指标

智能体上线后，评估不能只盯单一指标，视频建议关注五个维度：

1. 端到端任务成功率，而非单步准确率——八步每步都对，不代表这件事办成了；
2. 人工接管率，越低越好但绝不能为零，归零往往意味着门控失效；
3. 单位任务成本，包括token、工具调用和人工时长；
4. 错误代价，即错误动作造成的金额损失；
5. 平均完成时间。

此外强烈建议上线前先跑影子模式：智能体给出方案由人执行，对比两者差异后再逐步放量。

Agent改的是流程，不是模型

再往上一层，智能体落地改变的其实是流程而非模型。人的角色从执行者变成规则制定者和异常处理者；流程必须留「人工入口」，任何关键动作都能被人叫停和接管；责任要提前讲清楚——智能体做出的决定，最后由谁签字。

梁老师用一个比喻收尾：把智能体当成一个新入职员工，你要给他岗位说明书（职责边界）、操作手册（工具）、试用期（影子模式）、还要给他一个上级（门控）。四样缺一，就不该放到生产环境。

压缩成五条铁律：先定边界再谈能力；先接系统再优化话术；先设计失败再设计成功；先跑影子再放线上；先看端到端再看单步。

最后三句话带走核心：对话式AI卖的是答案，智能体卖的是结果；结果是可以被考核的，这既是机会也是门槛；做智能体的分水岭不在于它多敢自动化，而在于它多知道什么时候该停手。