这次短更想记录一个很现实的判断：工作流一旦开始接触外部用户、业务数据或正式内容发布，人审节点往往不是多余，而是让系统真正能上线的关键。

很多自动化链路在 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 模板，越改越复杂，最后亲手把它改坏了。

当时出发点完全没问题。我只是想让结果更完整一点、更礼貌一点、格式更统一一点，于是不断往模板里加约束、加示例、加例外说明。每次改动都显得很合理，但累积到一起之后，模板开始越来越重，输出反而变得更飘。

补档说明：本文属于「AI 工程落地周记」系列，计划发布时间为 2025-02-07 10:20。当前先保留为草稿，后续补充真实案例、代码片段和复盘细节后再发布。

很多团队在做 RAG 优化时，容易把问题切成几个独立模块来看：Chunk 怎么切、检索怎么召回、重排怎么加、最后模型怎么答。表面上看这很合理，因为技术栈确实也是这么拆开的。但真正调过一轮系统之后就会发现，这几个环节并不是并列关系，它们是串联关系，而且前一个环节的决策会强烈限制后一个环节的上限。

也就是说，很多 RAG 项目效果不好，不是某一个组件单独弱，而是顺序没想清楚：一开始切分就把信息结构破坏了，后面再怎么改召回和重排，都只能在一堆不完整片段里做“最优选择”。

所以我现在更在意的是这条链路的顺序：先怎么切，再怎么召，再怎么排，最后才轮到模型组织答案。