AI Agent项目上线半年后，说几句真话

去年到现在，我经手了四五个AI Agent相关的项目，有的做客服、有的做知识库、有的做自动化流程。半年下来有些感受，不吹不黑，说说真实情况。

这些项目都不大，团队小、预算少、时间紧——可能跟大多数做Agent落地的人处境类似。

先说做得好的部分

Agent确实能干活，不是玩具。

最成功的一个项目是售后服务助手。客户是一家做工业设备的企业，售后团队每天要处理大量重复咨询——"产品怎么装""这个故障码是什么意思""质保多久"。以前他们需要3个人轮班接电话，现在AI处理了70%的常规问题。

这个项目上线的过程我在别处写过，这里不重复。核心结论是：对于"模式固定、答案明确、高频重复"的场景，Agent非常有效。

另一个做得好的点是：用户对AI的接受度比我想象中高。项目刚上线时我担心客户觉得"和机器聊天很蠢"，实际反馈是大部分用户根本不在意对面是人是AI，能解决问题就行。

有几个项目要么延期，要么效果远低于预期。

踩得最深的坑是：以为Agent什么都能做。

一个客户想做全自动的"智能采购助手"——从需求分析到供应商比价到下单付款全部自动化。我们花了两个月搭框架，发现根本行不通。原因很简单：采购决策涉及大量模糊判断（"这个供应商虽然贵但合作多年"），需要行业经验和人际关系，当前的Agent完全处理不了。

最后收缩范围，只做"供应商信息查询"和"比价表自动生成"两步，人工做最终决策。效果可以接受，但客户期望和实际交付之间有落差。

另一个问题：维护成本被低估了。

Agent上线不是终点。知识库要更新（业务变化）、Prompt要调优（模型更新后行为变了）、切换大模型版本后要重新测试。这些维护工作每周至少要花2-3小时。对很多小团队来说，这是个隐藏成本。

LangGraph vs Dify vs 手写代码——没有银弹。

如果团队有开发能力，项目流程复杂：用LangGraph。灵活度高，可以精确控制每一步的逻辑。我后面的项目基本都切到了LangGraph。

如果团队没有专门的后端，业务逻辑简单：用Dify。可视化编排降低了不少门槛。但Dify对自定义逻辑的限制比较多，流程复杂了反而更费事。

很小很简单的场景（比如一个FAQ机器人）：不需要Agent框架。直接写个Python脚本调API，配合Prompt模板，比用框架都快。

关于大模型选型：

回头复盘，这半年对"Agent适合干啥"有了更清楚的认识。满足以下条件的项目成功率更高：

1. 输入输出边界清晰

用户的问题范围是有限的（比如客服问询300个常见问题），而不是"任何问题都能问"。

2. 有确定的知识源

答案可以从知识库、API、数据库里明确查到，不需要AI"推断"或"猜测"。

3. 容错空间大

AI回答错了，后果不严重（比如推荐错了商品），不像"AI开错药"那样要命。

4. 人工兜底机制完善

AI处理不了的、处理得不好的，能顺畅地交给人工。这个看起来简单，实际做起来很考验系统设计。

先手写验证，再上框架。

花1-2天用Python写个原型，连上API，手动测试几十个case。效果好才上框架，效果不好就直接放弃或换方案。不要一上来就在Dify/LangGraph里拉半天流程，结果核心逻辑不行。

先窄后宽。

一开始只处理最核心的3-5个场景，跑通跑稳了再扩展。不要想着一步到位覆盖所有场景。

预留人工干预接口。

在任何决策节点上都留"人工接管"的能力。这不仅是兜底，也能让你在AI不擅长的环节里收集数据，逐步优化。

做好上线后持续改进的预算。

不是代码写完就完事了。知识库更新、Prompt调优、异常处理——这些是持续投入。

---

以上是一些个人感受。AI Agent这个领域变化很快，现在的经验可能半年后就过时了。但"工具只是工具，场景决定价值"这个判断，应该不会变。