在我工作中，向 Notion 内部其他部门推广 AI Agent 并为企业提供基于 FDE 方法的实施支持时，我发现了一些规律。我为销售、内部销售、营销、产品开发、客户成功等部门构建过 Agent，但它们在现场层面都面临共同的障碍，在组织层面也有结构性问题。这两类障碍都无法避免，而我认为大多数公司都卡在了同样的地方。
▍现场障碍
① 范围过小的问题
我曾尝试为销售做一个 Agent，功能是“收到潜客时自动调研”。我设想的完整流程是：当潜客进入列表时，Agent 自动调研内外部信息，然后生成邮件草稿。我首先搭建了当新潜客进入数据库时自动调研信息的部分——我本以为，基础打好之后，自动生成邮件草稿会很顺利。
然而，当我把初始版本交给一线团队后，几周过去了，他们仍然没有自动化邮件草稿。我去回访时，他们说：“光是能自动调研潜客就已经很方便了！”大家根本没意识到还能做到邮件草稿这一步，或者压根没想过能自动化到那种程度。似乎他们也有顾虑，觉得这事太难。
这就是 Agent 落地停滞的第一个模式：把工作范围设定得太小，即便 Agent 已经搭好，最终只被用来做零散的功能或小任务，回报率很低。
② 因范围过大而停滞的问题
第二个问题正好相反：想把一个复杂的业务流程做成 Agent，却发现流程本身缺乏清晰的分解。不同人操作方式不同，或者隐性知识太多。试图做得很全面，结果光访谈环节就耗费大量时间，始终进不到开发阶段。相关方越来越多，达成共识的成本急剧上升。最初的热情慢慢消退……
这是项目管理中的范围设定问题。你想用 Agent 做什么？想达成什么结果？如果结果定了，Agent 的必要且充分范围也就确定了。模糊地喊着“用 Agent 提升业务效率”，就会陷入泥潭。
③ 缺乏主人翁意识
即便有推动者一鼓作气搭建了 Agent，但如果改进或修复 Bug 的责任不明确，使用量会逐渐下降。推动者也会失去动力。理想状态下，一线团队应该把 Agent 当作自己的东西来维护。如果这一点缺失，头三个月看起来不错，但后面就无法规模化。随着相关方增多——尤其是工作范围变大——需要协调和确认的事情越来越多，那种“谁拥有它”的归属感就会逐渐稀薄。
这三个问题并不是孤立的，而是相互关联的。范围设计错了，主人翁就建立不起来；没有主人，范围也不会扩大。
▍组织层面的障碍
即使克服了现场障碍，在企业环境中，仅仅“做出一个能用的东西”之外还有四道墙。
④ Token 资本透明度
即使按部门能看到 Token 消耗量，往往也不清楚“具体做了什么工作、获得了什么成果”。从 Token 资本和 Token 管理的角度看，这会成为问题，导致无法为预算提供正当理由。结果，管理层只把 Token 看作消耗成本，问道：“那得要多少钱？”
⑤ 治理
谁能创建 Agent、谁能看到它们、谁来管理它们？如果这些不明确，组织里就会涌现大量“流浪 Agent”或“僵尸 Agent”——在运行却没人用。没人承担责任，预算得不到保障，Token 被浪费，安全风险增加，直到一切停摆。
⑥ 可观测性
Agent 运行了多少次、成功了多少次、在哪里失败了？这是运营的最低要求，但很多工具在这方面都很薄弱。看不到的东西就无法改进。只有具备可观测性，才能建立 Agent 改进的反馈闭环。
⑦ 模型选择的灵活性
过度依赖某一家大模型供应商存在风险。万一它性能暂时下降？万一故障停服？万一出口限制导致不可用？如果不能立刻切换到其他供应商，就无法把 Agent 直接嵌入业务流程。AI 已经变成基础设施，但极度的单点依赖目前却被盲目容忍。
总结
Agent 落地看起来是个技术问题，实际上关乎业务设计和所有权。要确保它不只是“AI 真厉害”的昙花一现，需要先打好治理和可观测性的基础。
不能太小，不能太大，还要有人负责任地持续维护。同时，组织层面也要有支撑体系。我认为只有当现场和组织两者同频时，Agent 才能真正扎根。
