关于我们与人工智能代理的现状的随意发言：

有些人不称他们为代理，而是称为“工作流代理”，它们无处不在并且有效。任何人都可以构建简单的工作流代理，甚至可以从像 Zapier 和 n8n 这样的无代码工具开始。复杂的工作流代理需要更多的思考，以可靠和高效的方式构建。一个针对常见且有价值的用例的复杂工作流，内置相关集成，可以独立作为一项业务，同时也是一个很好的市场进入策略，以便后续扩展到其他工作流或更自主的工作。

越来越多的动态/自主代理开始工作，并且对研究（尤其是基于网络的）和编码非常有帮助。一旦开始添加更多数据源（例如API），它们的可靠性就会降低。只读代理感觉安全且易于测试，但让自主代理采取行动（写入）则令人感到害怕。（对此的一个随机想法：如果像CRM这样的工具允许你“分叉”一个开发镜像并运行可以回滚或合并的自动化实验，那就太酷了。）

动态代理在以下情况下表现良好：(1) 制定并跟踪一个好的计划；(2) 正确执行任务；同时 (3) 找到合适的上下文以便在每一步（包括规划和每个任务）中进行输入。最后，它需要 (4) 在过程中进行反思（无论是否有人输入），以便能够适当地调整计划，并改善执行失败或表现不佳任务的方式。

任务规划：LLM 的推理能力 对于不需要私人背景的简单任务列表（例如深度研究，只需一系列网络搜索并进行总结）效果良好。如果你想研究很多实体，深度研究的效果就不那么理想，因为任务列表管理相对基础。基于电子表格的 AI 工具在研究多个实体时效果更好，因为你实际上是将任务管理转移到电子表格上，因为在提示之间传递长任务列表在这里并不奏效。编码代理中的任务管理适用于简单问题、简单代码或从头开始时。一旦进入更复杂的现有项目，它们的可靠性就会降低——开发者通过记录他们的代码如何工作和组织（.md 文件）来提高可靠性，这使得代理能够构建更有信息的任务列表。复杂代码需要更多文档，并最终动态提取这些文档中相关的上下文。许多人/企业对处理项目的正确顺序/方法/工具有强烈的未记录意见，我们需要更多的方法来提前和即时记录这些内容。编码和基于网络的研究代理工作良好的另一个原因是它们都使用相同的工具集，因此无需“学习”如何使用这些工具（下文将详细介绍）。

任务执行：任务通常是 API 调用（需要身份验证并理解如何使用 API 及其底层数据结构——这可能是独特的，例如在具有自定义表/列的 CRM 或数据库中）、LLM 推理（例如总结）、组合，甚至工作流代理*。研究代理实际上只是循环中的网络搜索和总结。编码代理是在您的代码库上进行 CRUD 操作，也许还会进行网络搜索以学习 API。身份验证和基本 API 访问似乎已经解决（MCPs 适合这里），但我希望看到更多关于工具特定上下文的内容（询问用户，但也在初始连接时进行分析，深入现有数据以了解工具的使用方式、数据结构、我们使用该工具的场景/项目）。错误/反思/反馈需要转化为有组织的学习，并在相关时作为上下文反馈。相同的工具可以在不同的组织中用于不同的目的和方式，我们需要以某种方式捕捉/记录这一点，以便有效执行任务。

背景：想象一下，作为一名新员工在公司工作。你在入职培训期间学到了很多（入职培训越好，你的起步就越有效），然后就是在工作中学习，这可以分为从组织的经验中学习（“我们是这样做的”）和从自身经验中学习——前者在大型组织中更为突出。上下文管理类似。上下文有多个层次，比如元（用户/公司）、项目/部门特定、任务特定、工具特定等。我们已经从简单的系统提示演变为混合的RAG策略（向量、关键词、图形），但除了拥有数据/上下文外，我们还需要指导，了解何时以及如何检索上下文，这在今天的早期版本中有所体现——但仍有很大的改进空间。这不仅仅是一个技术问题，也是一个商业问题——因为你基本上需要创建一个覆盖你预期的每种场景的入职文档。随着项目变得越来越复杂，正确修剪上下文需要更多的深思熟虑，以便在提示中仅包含相关信息，同时最小化不相关的上下文。

反思：我们有代理监控工具，可以覆盖LLM/api成本和观察，但分配成功/失败是一个挑战——编码代理在这方面比其他代理有优势，因为它们以确定性的方式注意到失败（通过代码测试）。对于许多其他代理任务，我们仍在寻找收集人类输入以改善未来输出的正确方法。根据我所知，今天的反思是人机协作，反馈主要被提供给人类开发者以改善代理，但当我们找到将反思转化为自我改进的方法时，才会解锁——即代理从任务列表生成和任务执行中的失败中获取见解，以便下次做得更好。基本上，反思需要转化为良好组织的上下文，只有在相关时才能被提取到提示中。这演变为对代理的微调，然后是代理强化学习环境——在这方面仍然感觉相当早。

*我之前提到过将任务交给工作流代理，这在你的代理受益于没有工作流代理作为工具时开始变得有意义（与每次都要弄清楚已知任务列表相比），或者当你的系统复杂到专门的代理拥有专门的上下文和工具时表现更好。或者如果你正在利用其他人构建的代理（我在这里开始看到的一个模式是自然语言API端点，以便更轻松的代理协作）。

如果我们今天的模型质量具备无限的内容窗口（没有质量下降）、无限的计算能力、无限的存储、浏览器访问权限，以及一种支付方式，那么单个 LLM 循环可能足以完成很多工作。 上述无意义观点的要点（没有什么是无限的）在于，代理编排在很大程度上是关于通过结构和代码来管理限制，从而将工作从 LLM 中卸载的方式。

生产中的代理有多种形式：作为内部工具，作为结合各种工具的独立产品，以及作为核心工具的一个功能嵌入。它们可以是通用的或专业的。聊天、语音和后台代理似乎是触发代理流程最常见的用户界面。

我还缺少什么？