夜雨聆风好久没更新文章了，过去一段时间，我们在做一件看起来很简单、实际很复杂的事：让 AI 参与真实业务履约。
很多人做业务 AI，第一反应是：把模型接进来，让它理解用户问题，然后调用系统完成动作。
这句话听起来很简单，但真正落到业务里，会很快遇到一个问题：
AI 到底应该负责什么？业务系统又应该负责什么？
如果这个边界没划清楚，AI 很容易变成一个“看起来很聪明，但随时可能越权、误判、乱走流程”的黑盒。
我们在一个服务履约类业务里，做过三版方案。业务本身并不复杂：服务者咨询订单，系统判断她能不能接单；接单后联系客户、上门服务、提交完成、跟进评价，最后处理结算。
看起来是一个普通流程，但里面有大量真实业务约束：
订单是不是她的？订单有没有被别人接走？服务时间是不是已经过了？服务项她能不能做？完成状态能不能提交？评价是否达标？结算是否满足条件？异常时能不能直接找客户要钱？
这些问题不是“回复得像不像人”的问题，而是“能不能安全地做业务”的问题。
第一阶段：让 AI 做判断，代码做执行
第一版方案很直接：Workflow + 业务代码。
AI 做意图识别和初步决策，业务代码根据协议执行业务逻辑。业务系统前面有一层控制层，通过后端接口完成查询、校验和动作执行。
这种方式很务实。
它的优点是控制力强。AI 只负责判断用户大概想干什么，真正的权限、状态、异常处理都在代码里。对于客服、咨询、简单工单这类场景，它的响应速度也很低，链路短，稳定性好。
但它的问题也非常典型：
当业务场景不断增加，Workflow 会越来越像一张补丁网。
一开始只有几个意图，后来变成十几个，再后来接近二十个。每多一个场景，就要补分支、补协议、补后端逻辑、补测试。
更难的是，用户表达无法穷举。
同样是“我能不能去”，可能是在找单；
同样是“做完了”，可能是提交完成；
同样是“钱呢”，可能是正常催结算，也可能是评价没达标，也可能是订单根本不是她的。
如果 AI 只在开头做一次判断，一旦判断错了，后面的代码只能围绕错误输入兜底。
所以 V1 的本质不是“旧”，而是它选择了一个边界：
把不确定性尽量压在入口，把确定性留给代码。
这适合低复杂度、高频、规则稳定的业务。但当场景持续增长，维护成本会越来越高。
第二阶段：把业务能力工具化，让 AI 反复理解和行动
第二版开始，我们改变了思路。
既然用户表达无法穷举，那就不要让 AI 只做一次分类。我们把订单查询、服务者识别、派单判断、状态更新、评价审核、结算处理等能力，拆成可调用的业务工具。
AI 不再只是入口分类器，而是可以根据上下文，多步调用工具，再基于工具结果继续判断。
这带来一个明显变化：
业务从“流程驱动”变成了“能力驱动”。
V1 里，流程写死在 Workflow 和代码分支里。
V2 里，业务能力被工具化，AI 可以围绕问题动态组合这些能力。
比如服务者说：“这个我能接吗？”
系统不应该只靠一句话判断。它需要先确认服务者是谁，再查订单，再判断订单状态、归属、城市、服务项、时间，最后才决定能不能接。
这类问题，工具化 Agent 的泛化能力明显更好。
从测试集结果看，即使还在 Demo 阶段，V2 对复杂表达和非标准场景的覆盖已经优于 V1。它的优势不是“更会聊天”，而是维护方式变了：
以前增加场景，要补 Workflow 分支。
现在更多是补工具能力、补状态返回、补评测 Case。
但 V2 也暴露了业务 Agent 最关键的风险：
AI 会调用工具，不代表它有权限调用工具。
真实业务里的工具分两类：
一类是查询类，比如查订单、查服务者、查上下文。
另一类是修改类，比如绑定订单、更新履约状态、提交完成、处理结算。
查询错了，最多回复不准；
修改错了，就会改变真实业务状态。
所以不能只靠提示词告诉 AI：“你要谨慎一点。”
提示词是软约束，业务系统需要硬约束。
这时，我们开始引入三个概念：
权限闸门状态机评测集
权限闸门解决“谁能操作什么”。
状态机解决“当前状态能不能流转”。
评测集解决“我们怎么证明它在复杂场景下没有乱来”。
这一步很重要。因为它标志着我们不再把 Agent 当成一个聪明的对话模型，而是开始把它当成一个需要治理的业务执行者。
第三阶段：业务 Agent Runtime
到了第三阶段，我们面对的问题又变了。
如果只有一个业务，V2 已经可以跑起来。
但如果未来有多个业务都要接入呢？
服务履约要接入，售后要接入，审核要接入，结算要接入。每个业务都有自己的身份、上下文、意图、路由、工具、状态机和回复策略。
如果每个业务都各写一套 Agent，很快会变成新的混乱。
所以第三版的目标不是“再做一个更聪明的 Agent”，而是抽象一套业务 Agent Runtime。
它要解决的是工程化问题：
业务怎么接入？工具权限怎么统一治理？状态和审计怎么保存？评测怎么标准化？多人怎么协作开发？新业务怎么不污染通用架构？
在这一版里，我们把系统拆成几层：
Runtime：负责通用编排、状态、审计、工具护栏Business Module：负责具体业务规则、意图、路由、回复Tools：负责业务事实、权限校验、状态流转LLM：负责理解、推理和表达Eval：负责证明效果
这里有一个非常关键的原则：
业务逻辑不能污染 Runtime。
Runtime 不应该知道“订单怎么派”“评价怎么算”“什么时候结算”。
它只负责固定的执行骨架：
确认身份加载上下文理解意图选择路由调用工具生成回复记录审计
具体业务规则放在业务模块里。
这样做的好处是，未来新增一个业务，不需要改主图，不需要复制工程，只需要新增一个业务模块，实现自己的身份、上下文、意图、路由、工具和回复。
这就是 V3 的价值：
它不是让单个场景更快上线，而是让多个业务可以长期、稳定、可治理地接入 Agent。
当然，它也有代价。
它需要更强的工程设计，需要定义协议，需要写评测，需要维护状态和审计。对于简单场景，这可能是过度设计。
所以 V3 不是最终答案，也不是所有业务的最优解。它适合的是复杂度已经上来、生命周期足够长、并且业务对权限和状态要求很高的场景。
真正的演化：不是模型变强，而是边界变清楚
回头看这三版，技术形态确实在变化：
V1：Workflow + 业务代码V2：Agent + 工具化服务V3：业务 Agent Runtime
但这不是最重要的。
真正重要的是，我们越来越清楚地划分了三类能力：
模型负责不确定性业务系统负责确定性Runtime 负责治理性
模型适合处理自然语言、多样表达、上下文理解和柔性回复。
业务系统适合处理权限、状态、数据一致性和真实动作。
Runtime 适合处理编排、审计、限流、评测和可维护性。
如果让模型负责确定性，它会不稳定。
如果让代码穷举不确定性，它会越来越重。
如果没有 Runtime 治理，两者连接起来后就会失控。
这才是业务 AI 落地的核心矛盾。
不是“用不用 Agent”。
而是“哪些事情应该交给 Agent，哪些事情绝不能交给 Agent”。
怎么选 V1、V2、V3？
我的结论比较务实。
如果业务场景稳定、规则少、响应速度要求高，V1 是非常好的选择。
适合：标准客服、简单查询、规则稳定的工单优势：快、稳、可控问题：场景多了之后维护成本高
如果业务表达复杂、场景无法穷举，但业务动作可以工具化，V2 是很好的验证路径。
适合：中等复杂度业务、多场景服务履约、需要快速验证 Agent 效果优势：泛化强、维护成本低于 Workflow问题：必须补权限闸门和状态机
如果业务会长期演进，涉及多角色、多状态、多工具、多业务接入，而且对审计、评测、权限要求很高，就应该考虑 V3。
适合：复杂履约、售后、审核、结算、跨系统协同优势：可治理、可扩展、可长期维护问题：建设成本更高，不适合简单场景
所以不是 V3 一定比 V2 高级，也不是 Agent 一定替代 Workflow。
更准确的判断是：
复杂度没到，Runtime 是负担；复杂度到了，没有 Runtime，Agent 很难进入真实业务深水区。
最后
很多 AI 项目失败，不是因为模型不够强，而是因为系统没有想清楚边界。
AI 可以像大脑一样理解问题，但真实业务不能只靠大脑。
它还需要手脚，需要规则，需要刹车，需要仪表盘。
业务 Agent 真正要解决的，不是“能不能回复”，而是：
能不能理解复杂表达能不能调用正确工具能不能遵守权限能不能尊重状态能不能处理异常能不能被评测证明可靠能不能长期维护
当这些问题都被纳入设计，AI 才不是一个外挂能力，而会变成业务系统的一部分。
这也是我对业务 AI 的一个阶段性判断：
AI 落地的关键，不是让模型替代系统，而是重新设计模型和系统之间的分工。
