补档说明：本文属于「AI 工程落地周记」系列，计划发布时间为 2025-02-27 14:30。当前先保留为草稿，后续补充真实案例、代码片段和复盘细节后再发布。
过去一段时间，围绕 AI 工程的讨论里有个很容易被低估的主题，就是“工具到底该怎么接”。早期大家的做法非常朴素：每个产品、每个 Agent、每个工作流，各自写一套工具适配层，需要什么接什么，能跑就先跑。这个阶段没错，它能帮助团队快速验证想法。但只要工具数量一多、协作角色一多，问题很快就会暴露出来。
最典型的情况是：同一个搜索能力，这边接一套协议，那边接一套字段；一个知识库服务，给不同的 Agent 暴露出不同的调用方式；日志、权限、重试和错误语义也都各写各的。短期看很灵活，长期看就是一堆重复劳动和维护成本。
我觉得 MCP 值得关注，不是因为它“又定义了一个新接口”，而是因为它试图把工具接入这件事，从“每个应用自己发明协作方式”，往“围绕统一协议定义边界”推进了一步。它真正改变的，是协作边界，而不仅仅是接口风格。
补档说明：本文属于「AI 工程落地周记」系列，计划发布时间为 2025-03-14 20:15。当前先保留为草稿，后续补充真实案例、代码片段和复盘细节后再发布。
过去几个月，几乎所有做 AI 应用的人都会碰到一个问题：这件事到底应该设计成 Agent，还是设计成 Workflow？一开始我对这个边界也没有特别强的判断，很多场景看起来都“可以上 Agent”，因为它听起来更灵活、更聪明、更接近用户对 AI 的想象。
但做过几轮之后，我反而越来越保守。我现在更倾向于把 Workflow 当成默认选项，把 Agent 当成例外选项。不是因为 Agent 没价值，而是因为大多数业务流程真正需要的不是自由发挥，而是稳定、可解释、可观测、可回退。
换句话说，Agent 的价值在于处理不确定性；Workflow 的价值在于约束不确定性。真正的设计重点，不是二选一，而是先判断你的业务到底更怕哪一种东西。
补档说明：本文属于「AI 工程落地周记」系列，计划发布时间为 2025-03-18 11:40。当前先保留为草稿，后续补充真实案例、代码片段和复盘细节后再发布。
如果只允许我用一个事故来解释这篇文章，我会选“重复建单”。
场景很简单：我们做了一个退款助手，模型拿到用户问题后，会先调 searchOrder 确认订单状态，再调 createRefundTicket 创建退款工单，最后调 notifyAgent 给人工客服发提醒。这条链路在演示时很顺，因为每次只跑一单，也很少超时。
真正的问题发生在灰度流量上来以后。有一类请求会卡在 createRefundTicket 这一步，工具其实已经成功落库，但响应在网关层超时了。系统把这次调用当成失败，又自动重试了一次。于是第二张退款工单被建出来了。
最糟糕的地方在于，当时我们第一眼根本看不出来问题在哪。业务方看到的是“怎么有重复工单”，模型侧看到的是“工具偶尔失败”，后端看到的是“数据库写入成功”。如果没有一条完整的 trace，这个问题会像鬼一样，到处出现，但没人知道是谁干的。
补档说明：本文属于「AI 工程落地周记」系列，计划发布时间为 2025-03-23 21:30。当前先保留为草稿，后续补充真实案例、代码片段和复盘细节后再发布。
2025 年 3 月 11 日之后，我对 AI 应用的一些判断开始变得更明确了。不是因为那天突然出现了一个完全颠覆的新世界，而是因为“工具调用”和“围绕工具调用组织工作流”这件事，被越来越正式地推到了台前。那之后我更确定了一点：很多 AI 产品的价值中心，正在从“模型单次回答得多聪明”，转向“系统能不能围绕模型把事情做成”。
这两者看起来只差一点点，实际是完全不同的工程重心。
前一种重心下，团队更容易围绕 Prompt、模型榜单、单次回答效果去优化；后一种重心下，团队会开始更认真地讨论：
我觉得这就是为什么“工作流 + 工具调用”在这个时间点之后显得更重要了。因为它把 AI 应用从“会说话”推进到了“能协作、能执行、能被治理”。
补档说明：本文属于「AI 工程落地周记」系列，计划发布时间为 2025-03-30 10:20。当前先保留为草稿，后续补充真实案例、代码片段和复盘细节后再发布。
这次短更想记录一个很现实的判断：工作流一旦开始接触外部用户、业务数据或正式内容发布，人审节点往往不是多余，而是让系统真正能上线的关键。
很多自动化链路在 Demo 阶段看起来都很顺，因为样本干净、场景单一、风险还没真的压上来。但只要开始进入真实业务，团队很快就会发现，完全自动执行的吸引力，往往比不上“可控上线”的价值。
补档说明：本文属于「AI 工程落地周记」系列，计划发布时间为 2025-05-22 11:40。当前先保留为草稿，后续补充真实案例、代码片段和复盘细节后再发布。
这次短更想记录一个很直接的收益：加上一层像样的工具调用 trace 之后，一次原本要靠猜半天的问题，几分钟就定位到了。
问题表面上是“回答质量偶尔变差”，但真正看了 trace 之后，很快就能看到：不是模型理解错了，而是某个工具返回慢了一次，后面的重试触发了 fallback，最终结果自然就偏掉了。
补档说明：本文属于「AI 工程落地周记」系列，计划发布时间为 2025-05-30 21:30。当前先保留为草稿，后续补充真实案例、代码片段和复盘细节后再发布。
如果只用一个真实项目来说这篇文章，我会选“内容同步流水线”。
这条流水线要做的事情其实不复杂：
这类事情非常适合用 n8n 这类工作流工具来做。因为它的核心难点不是算法，而是“把几个系统串起来”。可问题也正是在这里：很多团队一看到可视化编排很方便，就会很自然地把更多业务逻辑一起拖进去，最后把工作流画布变成半个业务系统。
所以我越来越觉得，n8n 这类工具最容易被误用的地方，不是功能不够，而是边界不清。
补档说明：本文属于「AI 工程落地周记」系列，计划发布时间为 2025-06-06 10:20。当前先保留为草稿，后续补充真实案例、代码片段和复盘细节后再发布。
如果只谈“生成一篇内容”，现在的大模型其实已经能做得像模像样了。真正把团队拖进泥里的，往往不是生成这一步，而是后面三件更现实的事：
我之所以会把这个问题单独拉出来讲，是因为我见过太多内容自动化项目，一开始都卡在“怎么生成得更好”，结果真正上线后最先出事故的，都是审核和回滚链路。
最典型的一次，是一条自动生成的内容流里，模型把一个引用来源写错了。正文本身看起来挺顺，发布动作也正常完成，但问题在于：
这时候真正难的已经不是“修正文案”，而是“怎么让整条发布链恢复一致”。
补档说明：本文属于「AI 工程落地周记」系列，计划发布时间为 2025-06-13 21:30。当前先保留为草稿，后续补充真实案例、代码片段和复盘细节后再发布。
很多团队在接入大模型之后，都会很快进入一个误区：只要某个功能里有“判断”“调用工具”“多轮交互”这些词，就想把它包装成 Agent。看起来好像更先进，也更符合行业叙事。
但真落到工程里，很多小功能的问题恰恰在于它们太小了，小到根本不值得引入 Agent 这一整套复杂度。
我后来越来越明确的一条原则是：能用一次结构化调用解决的问题，不要先升级成带规划、带循环、带状态恢复的 Agent 任务。
这不是保守，而是成本意识。因为对一个小功能来说，Agent 带来的往往不是“更强能力”，而是额外的系统负担：
补档说明：本文属于「AI 工程落地周记」系列，计划发布时间为 2025-06-19 20:15。当前先保留为草稿，后续补充真实案例、代码片段和复盘细节后再发布。
工作流只在单系统里跑的时候，凭证问题常常被低估。很多团队一开始会觉得，不就是在环境变量里放几个 token 吗？等到真的开始跨系统：
这些 token、key、secret 就会突然从“配置细节”变成整条工作流最脆弱的一层。
我后来对这个问题印象最深的一次，是一个看起来很普通的内容发布工作流。它需要同时访问：
结果真正先出问题的，不是业务逻辑，而是凭证边界混乱：有的 token 权限过大，有的 token 被多个流程共用，有的过期了没人知道，还有的出错日志里直接把敏感信息暴露出来。
从那之后我才真正把“凭证管理”当成跨系统工作流的核心设计问题，而不是交给运维顺手处理的附属项。