我研究AI代理已经有一段时间了，每次深入探索后，我都有同样的感觉：这些东西在受控演示中看起来令人印象深刻，但一旦你试图将它们应用到实际工作流程中，它们就会崩溃。
我发现的大多数关于如何创建AI代理的教程要么是玩具示例（总结这个PDF，回答关于CSV的问题），要么是过于抽象，以至于我无法弄清楚如何将它们映射到实际的业务流程。我的团队处理一个相当复杂的销售运营工作流程，数据分布在CRM、几个内部工具和一些从未被正式记录的手动交接步骤中。一个能够处理其中哪怕一部分工作的代理的想法很有吸引力，但我真的怀疑这项技术是否已经成熟，除了资金充足的企业试点项目之外。
有没有人实际部署过在生产环境中运行的东西，而不仅仅是存在于笔记本中的概念验证？我想要具体信息：你使用了什么工具或平台，它实际接管了什么工作流程，以及它在哪些地方让你失望或崩溃。我不是在寻找炒作，而是在寻找经历过挫折并能告诉我什么是真实的人。
从演示到实际应用的差距几乎从来不是模型本身，而是工具和故障处理。先拿你的销售运营流程，把它写成一份简单的脚本，硬编码CRM和内部工具中的快乐路径。然后只把需要判断的步骤交给LLM，比如选择匹配的记录或起草后续跟进。为每个工具提供类型化的输入，并在任何操作继续之前验证其输出，同时记录每次调用，以便查看哪里出了问题。一个能可靠完成三个步骤的智能体，胜过尝试二十个步骤却悄悄破坏数据的智能体。
farhadnawab已经指出了关键点（是数据可靠性和决策边界，而不是模型），所以我补充一下对我有帮助的部分：不要试图自动化整个工作流程，而是自动化其中一个重复的步骤，并在任何重要操作上设置人工批准按钮。
演示在投产中失败的原因不是能力，而是信任。一个自主操作CRM的代理必须每次都正确，否则就会造成损害，而没有任何东西能每次都正确。但是，一个起草更新并等待一次点击的代理在85%的准确率下是有用的，因为人类可以捕捉那15%的错误，只要草稿能一目了然地审查，而不是一堆你只会盲目批准的输出。只有当你能真正看到变化时，这个门控才有效，但当它有效时，它能让不可靠的东西变得可交付。
所以对于你的销售运营混乱：不要把代理指向“工作流程”。选择最烦人的重复交接，让它生成完成的草稿（邮件、CRM更新、摘要），并让你参与批准。这样就能交付。“代理无人值守地运行整个流程”则不行，而且说实话也不应该。（我在这方面做开发，所以撞过几次墙。）
是的，我实际上已经为客户在生产环境中部署了几个这样的系统，诚实的答案是，演示与实际工作流程之间的差距几乎完全在于数据可靠性和决策边界，而不是AI本身。
演示之所以有效，是因为一切都很干净且范围明确。你的销售运营工作流程中存在混乱的CRM数据、未记录的交接以及没有人记录过的边缘情况。智能体遇到这些问题时，要么会幻觉出一条前进路径，要么直接停止。两者都很糟糕。
对我们真正有效的方法是，从一个交接步骤开始，最烦人的那一个，就是有人手动在两个工具之间复制粘贴，或者每周写30次相同邮件的那一步。不要试图自动化整个工作流程。先让那一个部分在生产中可靠运行。这也会迫使你记录逻辑，而你的团队可能本来就需要这样做。
在工具方面，当客户想要自托管时，我们使用n8n进行编排，并混合使用OpenAI函数调用和自定义逻辑作为决策层。平台的重要性不如你如何定义智能体可以自主决定什么以及需要交回给人类处理什么。
它在哪里会出问题？任何需要基于不完整信息进行判断的情况。如果CRM记录缺少字段，或者两个工具的数据冲突，智能体会自信地做错事，除非你明确处理了这种情况。而且你无法预先处理所有情况，所以你会在生产中发现失败。这就是现实。
在开始构建之前，我会问你的团队一个问题：你能写下新员工完成这项任务所需遵循的确切规则吗？如果答案是否定的，那么智能体还不是你的问题，流程才是。