随意吐槽一下人工智能代理的现状：
有些人不称它们为代理，但具有确定性流程的“工作流代理”无处不在，而且行之有效。任何人都可以构建简单的工作流代理，甚至可以从 Zapier 和 n8n 等无代码工具入手。构建复杂且可靠的工作流代理则需要更多思考。针对常见且有价值的用例，并内置相关集成的复杂工作流，既可以独立作为一项业务，也可以作为未来扩展到其他工作流或更自主工作的绝佳市场推广方案。
更动态/自主的代理程序开始发挥作用，对研究（尤其是基于 Web 的）和编码很有帮助。但一旦添加更多数据源（例如 API），其可靠性就会降低。只读代理程序感觉安全且易于测试，但让自主代理程序执行操作（写入）则令人担忧。（关于这一点，我有个想法：如果像 CRM 这样的工具允许用户“fork”一个开发镜像并运行自动化实验，然后可以回滚或合并回主镜像，那就太好了。）
动态智能体要想高效运行，需要具备以下能力：(1) 制定并跟踪有效的计划；(2) 正确执行任务；(3) 为每个步骤（包括计划和每个任务）找到合适的上下文信息。最后，它还需要 (4) 在执行过程中进行反思（无论是否需要人工干预），以便适当调整计划，并改进执行失败或表现不佳的任务的方式。
任务规划：LLM的推理能力 对于不需要私密上下文的简单任务列表（例如深度研究，只需进行一系列网络搜索并进行总结），这种方法效果不错。但如果要研究大量实体，深度研究的效果就不理想了，因为任务列表管理相对基础。基于电子表格的AI工具更适合研究大量实体，因为任务管理实际上是将任务卸载到了电子表格中，而直接在提示之间传递冗长的任务列表在这里行不通。编码代理中的任务管理适用于简单的问题、简单的代码，或者从零开始的情况。一旦涉及到更复杂的现有项目，其可靠性就会降低——开发者可以通过记录代码的工作原理和组织结构（.md文件）来提高可靠性，这使得代理能够构建更完善的任务列表。复杂的代码需要更多文档，并最终动态地从这些文档中提取相关的上下文信息。许多人/企业对于处理项目的正确顺序/方法/工具都有着强烈的、未记录的观点，我们需要更多方法来预先记录并随时更新这些信息。编码和基于网络的调研代理之所以有效，另一个原因是它们都使用同一套工具，因此无需“学习”如何使用这些工具（下文将详细介绍）。
任务执行：任务通常是 API 调用（需要身份验证并了解如何使用 API 以及底层数据结构——例如 CRM 或具有自定义表/列的数据库，数据结构可能独一无二）、LLM 推理（例如，总结）、上述各项的组合，甚至包括工作流代理*。研究代理实际上就是循环中的网络搜索和摘要。编码代理是对代码库的 CRUD 操作，也可能是网络搜索学习 API。身份验证和基本 API 访问似乎已经解决（MCP 符合要求），但我希望看到更多关于工具特定上下文的信息（询问用户，但也需要在初始连接时进行分析，深入挖掘现有数据以了解工具的使用方式、数据结构以及我们使用该工具的场景/项目）。错误/反思/反馈需要转化为有组织的学习成果，并在相关时作为上下文反馈。相同的工具在不同的组织中可能用于不同的目的并以不同的方式使用，我们需要以某种方式捕获/记录这些信息，以便更好地执行任务。
想象一下你是一家公司的新员工。你会在入职培训期间学到很多东西（入职培训越好，你上手后的工作效率就越高），然后是工作中的学习，这又可以细分为从组织经验中学习（“我们就是这样做的”）和从自身经验中学习——前者在大公司中更为普遍。上下文管理与之类似。上下文分为多个层次，例如元数据（用户/公司）、项目/部门特定信息、任务特定信息、工具特定信息等等。我们已经从简单的系统提示发展到混合的红黄绿（RAG）策略（向量、关键词、图表），但除了拥有数据/上下文之外，我们还需要关于何时以及如何检索上下文的指导，我们目前看到了一些早期版本——但还有很大的改进空间。这不仅仅是一个技术问题，也是一个业务问题——因为你基本上需要创建一个涵盖所有预期场景的入职文档。随着项目变得越来越复杂，我们需要更加周全地思考如何正确地筛选上下文，以便只在提示中包含相关信息，同时最大限度地减少无关的上下文。
反思：我们拥有能够覆盖 LLM/API 成本和观察的智能体监控工具，但如何判定成功/失败仍然是一个挑战——在智能体编码方面，其优势之一在于能够确定性地发现失败（通过代码测试）。对于许多其他智能体任务，我们仍在探索收集人类输入以改进未来输出的正确方法。据我所知，目前的反思机制是人机交互，反馈主要提供给人类开发者以改进智能体，但真正的突破在于如何将反思转化为自我改进——即智能体能够从任务列表生成和任务执行的失败中汲取经验，从而在下次做得更好。简而言之，反思需要转化为组织良好的上下文，以便在相关时将其提取到提示中。这将逐步发展为对智能体的各个部分进行微调，最终构建智能体强化学习环境——目前看来，这还处于起步阶段。
*我之前提到过将任务交给工作流代理，当你的代理不需要工作流代理作为工具（而不是每次都去处理已知的任务列表）时，或者当你的系统足够复杂，需要使用具有专门上下文和工具的专用代理才能更好地工作时，这种做法就变得有意义了。或者当你正在使用其他人构建的代理时（我开始注意到的一种模式是使用自然语言 API 端点来简化代理之间的协作）。
如果我们拥有当今模型的质量，以及无限的内容窗口（质量不下降）、无限的计算能力、无限的存储空间、浏览器访问权限和支付方式，那么一个LLM循环可能就足以完成很多工作。 上面这个毫无意义的观点（没有什么是无限的）的重点是，代理编排主要在于通过构建结构和代码来管理限制，从而将工作从 LLM 中卸载出来。
生产环境中的代理程序形式多样：可以是内部工具，也可以是集成多种工具的独立产品，还可以是核心工具的内置功能。它们可以是通用的，也可以是专用的。聊天代理、语音代理和后台代理似乎是触发代理流程最常见的用户界面。
还有什么我没考虑到的吗？