如果只讲原则，这篇文章还是会显得空。所以我直接拿一个真实得不能再真实的例子来说：退款工单分诊。
这类任务的目标通常是把用户自然语言输入转成一个后续系统能继续处理的对象，例如：
团队最早的做法很常见：先让模型直接输出一段 JSON，大概长这样：
{
"title": "用户申请退款",
"summary": "用户表示重复支付，希望退款",
"tags": ["退款", "重复支付"]
}
看上去没毛病，前端也能展示，测试样本甚至都能过。但真正进系统后，这种 Schema 很快就会把问题暴露出来：它描述了内容，却没有描述动作边界。
真正让系统难受的不是模型会不会吐 JSON，而是下游根本不知道怎么用这个结果继续执行。
这次短更想记录一个很现实的判断：工作流一旦开始接触外部用户、业务数据或正式内容发布，人审节点往往不是多余，而是让系统真正能上线的关键。
很多自动化链路在 Demo 阶段看起来都很顺，因为样本干净、场景单一、风险还没真的压上来。但只要开始进入真实业务，团队很快就会发现，完全自动执行的吸引力，往往比不上“可控上线”的价值。
补档说明：本文属于「AI 工程落地周记」系列，计划发布时间为 2025-03-23 21:30。当前先保留为草稿，后续补充真实案例、代码片段和复盘细节后再发布。
2025 年 3 月 11 日之后，我对 AI 应用的一些判断开始变得更明确了。不是因为那天突然出现了一个完全颠覆的新世界，而是因为“工具调用”和“围绕工具调用组织工作流”这件事，被越来越正式地推到了台前。那之后我更确定了一点：很多 AI 产品的价值中心，正在从“模型单次回答得多聪明”，转向“系统能不能围绕模型把事情做成”。
这两者看起来只差一点点，实际是完全不同的工程重心。
前一种重心下，团队更容易围绕 Prompt、模型榜单、单次回答效果去优化；后一种重心下，团队会开始更认真地讨论：
我觉得这就是为什么“工作流 + 工具调用”在这个时间点之后显得更重要了。因为它把 AI 应用从“会说话”推进到了“能协作、能执行、能被治理”。
如果只允许我用一个事故来解释这篇文章，我会选“重复建单”。
场景很简单：我们做了一个退款助手，模型拿到用户问题后，会先调 searchOrder 确认订单状态，再调 createRefundTicket 创建退款工单，最后调 notifyAgent 给人工客服发提醒。这条链路在演示时很顺，因为每次只跑一单，也很少超时。
真正的问题发生在灰度流量上来以后。有一类请求会卡在 createRefundTicket 这一步，工具其实已经成功落库，但响应在网关层超时了。系统把这次调用当成失败，又自动重试了一次。于是第二张退款工单被建出来了。
最糟糕的地方在于，当时我们第一眼根本看不出来问题在哪。业务方看到的是“怎么有重复工单”，模型侧看到的是“工具偶尔失败”，后端看到的是“数据库写入成功”。如果没有一条完整的 trace，这个问题会像鬼一样，到处出现，但没人知道是谁干的。
补档说明：本文属于「AI 工程落地周记」系列，计划发布时间为 2025-03-14 20:15。当前先保留为草稿，后续补充真实案例、代码片段和复盘细节后再发布。
过去几个月，几乎所有做 AI 应用的人都会碰到一个问题：这件事到底应该设计成 Agent，还是设计成 Workflow？一开始我对这个边界也没有特别强的判断，很多场景看起来都“可以上 Agent”，因为它听起来更灵活、更聪明、更接近用户对 AI 的想象。
但做过几轮之后，我反而越来越保守。我现在更倾向于把 Workflow 当成默认选项，把 Agent 当成例外选项。不是因为 Agent 没价值，而是因为大多数业务流程真正需要的不是自由发挥，而是稳定、可解释、可观测、可回退。
换句话说，Agent 的价值在于处理不确定性；Workflow 的价值在于约束不确定性。真正的设计重点，不是二选一，而是先判断你的业务到底更怕哪一种东西。
这次排查很典型：业务方反馈“最近知识库回答突然变差”，但表面上看系统并没有报错，模型也没换，接口响应时间甚至还是正常的。真正的问题出在一个很容易被忽略的指标上，检索命中率突然掉了一截。
一开始大家本能地怀疑 Prompt、怀疑模型、怀疑重排，但继续查下去才发现，问题不是最后生成阶段，而是索引更新后，一部分文档的元数据缺失，导致相关片段虽然被召回了，却没有排进最终候选。
我越来越觉得，很多 AI 项目后期维护困难，并不是因为模型太难控，而是因为 Prompt 被当成了一堆零散字符串在使用。哪个页面要改一句，在哪个文件里搜一搜；哪个流程要加个限制，直接往模板里塞；哪个实验效果好一点，就把那段提示词复制到另一个地方。短期看，这种方式很快；长期看，它会让整个系统越来越难治理。
当 Prompt 还是一两个的时候，这种混乱不太明显。但只要项目开始进入多任务、多模型、多流程、多角色协作阶段，Prompt 很快就会变成一层隐形配置系统。它既决定输出质量，又影响业务行为，还会牵连评测、日志和回滚。到这个时候，如果还把它当作普通字符串处理，迟早会出问题。
所以我更关心的不是“某一版 Prompt 写得多漂亮”，而是“这套 Prompt 有没有可维护的组织方式”。
补档说明：本文属于「AI 工程落地周记」系列，计划发布时间为 2025-02-27 14:30。当前先保留为草稿，后续补充真实案例、代码片段和复盘细节后再发布。
过去一段时间，围绕 AI 工程的讨论里有个很容易被低估的主题，就是“工具到底该怎么接”。早期大家的做法非常朴素：每个产品、每个 Agent、每个工作流，各自写一套工具适配层，需要什么接什么，能跑就先跑。这个阶段没错，它能帮助团队快速验证想法。但只要工具数量一多、协作角色一多，问题很快就会暴露出来。
最典型的情况是：同一个搜索能力，这边接一套协议，那边接一套字段；一个知识库服务，给不同的 Agent 暴露出不同的调用方式；日志、权限、重试和错误语义也都各写各的。短期看很灵活，长期看就是一堆重复劳动和维护成本。
我觉得 MCP 值得关注，不是因为它“又定义了一个新接口”，而是因为它试图把工具接入这件事，从“每个应用自己发明协作方式”，往“围绕统一协议定义边界”推进了一步。它真正改变的，是协作边界，而不仅仅是接口风格。
大模型幻觉一直是个高频话题，但我越来越觉得，真正难缠的不是“模型会不会出错”，而是“系统知不知道它正在出错”。前者是模型能力边界，后者是工程设计问题。只要是概率系统，出错几乎不可避免；但一个 AI 功能能不能上线、能不能长期维护，关键在于它出错时有没有信号、有没有护栏、有没有回收路径。
很多团队会把幻觉理解成一个纯模型问题，于是自然会把主要精力放在换模型、换 Prompt、加限制词上。可真正进入业务之后，最危险的往往不是明显胡说八道，而是那种“看起来很像对、实际上悄悄偏了”的结果。因为这类错误更难被用户第一时间看穿，也更容易混进流程。
所以我现在的看法是：幻觉并不可怕，可怕的是系统既没有提前识别风险的机制，也没有在出错时给出信号。
这篇短更记录一个很典型的失误：我把一个原本表现还算稳定的 Prompt 模板，越改越复杂，最后亲手把它改坏了。
当时出发点完全没问题。我只是想让结果更完整一点、更礼貌一点、格式更统一一点，于是不断往模板里加约束、加示例、加例外说明。每次改动都显得很合理，但累积到一起之后，模板开始越来越重，输出反而变得更飘。