16 篇博文 含有标签「Agent」

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

很多自动化链路在 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 的价值在于约束不确定性。真正的设计重点，不是二选一，而是先判断你的业务到底更怕哪一种东西。

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

过去一段时间，围绕 AI 工程的讨论里有个很容易被低估的主题，就是“工具到底该怎么接”。早期大家的做法非常朴素：每个产品、每个 Agent、每个工作流，各自写一套工具适配层，需要什么接什么，能跑就先跑。这个阶段没错，它能帮助团队快速验证想法。但只要工具数量一多、协作角色一多，问题很快就会暴露出来。

最典型的情况是：同一个搜索能力，这边接一套协议，那边接一套字段；一个知识库服务，给不同的 Agent 暴露出不同的调用方式；日志、权限、重试和错误语义也都各写各的。短期看很灵活，长期看就是一堆重复劳动和维护成本。

我觉得 MCP 值得关注，不是因为它“又定义了一个新接口”，而是因为它试图把工具接入这件事，从“每个应用自己发明协作方式”，往“围绕统一协议定义边界”推进了一步。它真正改变的，是协作边界，而不仅仅是接口风格。

如果说 2023 年上半年大家还主要在讨论“模型能写什么”，那么到了下半年，问题已经逐渐变成“模型能不能做事”。这也是 Function Calling 很快变得重要的原因。