如果只允许我用一个事故来解释这篇文章，我会选“重复建单”。

场景很简单：我们做了一个退款助手，模型拿到用户问题后，会先调 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 项目效果不好，不是某一个组件单独弱，而是顺序没想清楚：一开始切分就把信息结构破坏了，后面再怎么改召回和重排，都只能在一堆不完整片段里做“最优选择”。

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

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

企业知识库是过去一年我见过最多的 AI 落地入口之一。几乎每个团队在讨论 AI 能做什么的时候，都会很快想到它：把文档喂进去、把制度接进去、把 FAQ 接进去，然后做一个“问什么答什么”的系统。这个方向当然成立，但也正因为看起来太成立了，大家很容易低估它背后的难度。

我现在一听到“我们想做一个企业知识库”，脑子里不会先出现模型，也不会先出现向量库，而是先出现七个问题。只要其中有几项答不清楚，我就不会建议直接开工。因为很多知识库项目，不是死在技术实现上，而是死在一开始的问题定义就不清楚。

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

这次失败实验发生在一个看起来很“稳”的场景里。我们当时做的是一段常见的知识问答链路：用户提问，系统从知识库里取回上下文，再让模型给出总结式回答。小样本测试时效果不错，前十几个问题几乎都能答到点上，所以团队一度觉得这个方向很顺。

但把样本放大一点之后，结果开始明显飘了。同样的提问方式，今天答得不错，隔几小时再测一次，回答里的重点就会变化；换一个近义表达，答案会突然把次要信息讲得很重，真正关键的结论反而变淡。