关于长期代理的思考

提供一些背景信息，让你了解来源：我曾是一家达到独角兽规模的SaaS公司的工程总监。我的团队负责的领域之一是自助入职。在过去的14个月里，我的4个小组一直在将这一经历重建为代理流程，试图复制一些销售辅助旅程的体验。 随着更好的模型和代理框架，我看到了代理能力的巨大改进。但入职是一个长期过程。许多客户需要90天以上的协助。你需要记住他们的目标、偏好、已发生的情况以及何时再次介入。 长期代理看起来很像工作流，但不是传统意义上的僵硬方式。以入职为例。有一个总体目标，分解为更小的任务。有些任务有依赖关系，而其他任务完全独立。而不是像Airflow、Zapier或n8n那样单一连接的DAG，你最终得到的是更接近于可能任务的断开图。 而且任务不是行动，而是一个有范围的目标。代理连接到该任务，可以执行多个操作、做出决策并进行调整，直到目标完成。这种抽象之所以有用，是因为它使两个重要事情变得确定性：下一步最佳任务是什么？我们如何评估任务是否实际完成？ 代理处理非确定性部分，找出如何实现目标。但系统不必信任它来决定下一步工作或简单地自我报告工作完成。这很重要，因为虚假任务完成是我在企业代理部署中遇到的最大问题之一，添加监督代理并不能可靠地解决它。 同样的原则适用于基础设施。假设用户上传需要验证的文件。你可以通过LLM传递文件ID和名称，让它调用验证工具。但现在模型可能会截断、修改或幻觉这些标识符。相反，构建一个附件收件箱，在LLM看到文件之前处理和存储文件。 因此LLM决定应该发生什么。确定性基础设施处理数据的移动。这消除了一整类幻觉。这就是我认为最大投资需要去的地方：零令牌架构。构建高质量工具并最小化它们从LLM所需的参数。 因为任务定义是声明性的，依赖关系和成功标准被明确定义，我也能够围绕它们构建一个编译器。这给了我两个有用的特性：我可以几乎即时测试工作流，更像单元测试而不是手动执行整个流程。LLM可以从现有信息生成或重新生成工作流，然后根据确定性规则编译和验证它们。 因此LLM不会发明一个工作流并希望它有效。它生成一个定义，系统验证它，并在有问题时可以修复它。 我在这里肯定没有涵盖长期代理的许多其他方面，比如内存层、为每个任务运行时生成代理等等。我可能会在以后写一些关于这些的内容。目前，这主要是为了澄清我自己的思路，我发现写作通常有帮助。希望对你们中的一些人也有用。