一概述
许多人说2025年是“AI代理之年”。没有人能就“AI代理”的定义达成一致，但大多数人会同意AI代理的自主性是不断变化的。一方面，有工作流程（每个步骤都是预先计划好的）。另一方面，有AI代理，它们在执行过程中决定做什么。可以将两者的区别归结为一个问题：谁在驱动——开发者还是模型？
这篇文章详细介绍了这两者的细节，然后深入探讨了当您尝试交付生产时会遇到的混乱的、超出教程范围的部分。
二工作流程
1.工作流程的核心部分
你可以随心所欲地实现工作流程，但从概念上讲，我认为直观的做法是将其视为一个简单的图表。图中的方框和箭头从不即兴发挥——每一步都是提前规划好的。
节点：每个节点都是一项工作，可能是一次LLM调用，可能是做一些数**算，也可能只是“发送这封电子邮件”。
边：将方框粘合在一起的箭头。它们表示“接下来去这里”、“如果X则跳过此块”或“并行运行所有这些，然后回到这里汇合”。允许循环。箭头会指向之前的盒子，直到有指令停止。
共享状态：一个节点可以悄悄地将其结果发送到队列中的下一个节点，或者将其放在整个图表都可以访问的公共白板上。
2.基本工作流模式
提示链接：将第一个LLM的输出直接送入下一个，然后再送入下一个，依此类推，就像传送带一样，每个站点都会添加一个贴纸。
路由：读取传入的请求并将其引导至知道如何回答的路径。
并行化-聚合：同时启动几个分支，然后收集并合并结果。
协调器-工作者：中央大语言模型(LLM)负责评估工作，将其拆分成清晰的子任务，并将它们分配给更小的大语言模型(LLM)。当所有成员都完成后，它会将各个部分整合在一起。（这看起来已经很像一个AI代理了）
评估器-优化器：一个人写作，另一个人评分，循环不断进行，直到分数最终保持在标准之上。
三AI代理
1.AI代理的核心要素
从本质上讲，AI代理只是一个LLM，带有一个指令来指示它如何行动，再加上一盒工具，当它需要外部系统或数据时就可以使用。其他一些重要部分维持着整个系统的运行：
执行循环（AI代理运行器）：LLM只能“说话”或以其他方式进行交流，例如图像；它无法点击按钮。一个连续循环读取生成的文本，确定正在请求的工具，触发调用，并将结果反馈给LLM。此循环重复进行，直到AI代理判断完成或触发停止条件。
上下文：上下文是LLM在思考时能够“看到”的信息片段。它涵盖了从枯燥但有用的内容（例如今天的日期、用户的访问级别）到会话中的闲聊（例如之前的留言、过去的工具调用）。虽然现在许多LLM都有很长的上下文窗口，但在多轮交互中，无关信息会迅速堆积，因此精简至关重要。
会话状态（短期记忆）：一个会话涵盖一次完整的运行——可能是五轮，也可能是五十轮。AI代理学习、决策或生成的所有内容都会保留在这里，直到会话结束。
长期记忆：当某些东西应该在会话结束后继续存在时——用户偏好、解决的问题、写了一半的代码——它就会被存放在数据库、向量存储或纯文本文件中。
交接：如果任务发生变化，例如从预订航班改为提交费用报告，当前座席可以将接力棒交给精通该领域的队友。交接不仅包含原始数据，还包含任务上下文、聊天记录以及当前对话的主导者。
生命周期事件：即使是自主运行也会遇到可预测的检查点：工具调用之前、LLM返回之后、下一个提示符之前等等。这些时刻对于日志记录、权限检查或在出现问题时提前终止运行非常有用。
2.AI代理的基本模式
单个AI代理只是一个LLM、它的指令和一个循环。当用户或其他系统将任务放到其桌面上时，AI代理就会启动。在循环内部，AI代理会规划下一步行动，调用所需的任何工具，并持续执行，直到它认为任务已完成，或者由于内置限制（例如，轮次或令牌数量上限）而终止。
单个智能体能够处理的工具和指令数量有限，否则就会因自身环境而出错。将负载分散到多个智能体上——每个智能体的任务描述更明确，工具包更轻量——通常最终会更加简洁可靠。以下是一些多智能体协作模式：
主管-工作者：中央AI代理持续与用户通话，同时将子任务分配给专门的工作者。工作者无需与用户对话。主管掌握全局并拥有最终决定权。
分类：与主管-工人设置的形状相同，但在对请求进行分类后，分类AI代理会将呼叫者交给正确的专家。
层次结构：更深的堆栈，其中每个专家可能都有自己的子团队，让树的深度随着问题的需求而增长。
顺序：AI代理排列成一条直线，每个AI代理接手前一个AI代理的交接任务。这类似于即时链接工作流，只不过是使用完整的AI代理，而不是单个LLM调用。
并行化-收集：同时启动多个AI代理，让它们并行工作，然后在继续之前合并它们的结果。
冗余：启动多个执行相同任务但方法不同的AI代理，比较它们的答案，保留最佳答案，或者合成一个新的答案。这种方法会消耗额外的资源，但会提高可靠性。
评审-批评：一个AI代理构建，另一个AI代理检查，如此循环，直到批评者满意为止。与评估-优化工作流程相同，但升级为完整AI代理。
升级：先从价格低廉、轻量级的AI代理开始。如果出现问题，则将工单升级到更重、能力更强（通常也更贵）的AI代理。这是一种内置成本控制的分类处理方法。
网络：每个AI代理都位于一个开放的通道上。其中任何一个AI代理都可以ping通其他AI代理，决定下一步由谁来执行，然后交接任务——无需中央调度。
四工作流与AI代理
两种方法的比较如下：
大多数人最终都会找到一个平衡点：给予AI代理足够的自由，使其能够发挥作用，但同时又要设置围栏，确保其安全、可见且不超出预算。工作流节点可以将杂乱的角落交给AI代理，而AI代理可以在需要稳定子任务时加入工作流。
五超越基础的考虑
连接几个基本组件，选择一个模式，你就拥有了一个AI代理系统。借助如今的开源框架，这实际上只需十行代码。教程看起来毫不费力，但实际生产环境却截然不同。以下是在实际用户使用之前你需要的额外工具。
1.护栏
LLM仍然会犯错，黑客仍然会钻空子。你需要技术和政策护栏，确保智能体在安全、合法性、成本和品牌形象的范围内运行。这些护栏并非一道单一的大门，而是层层递进的安全网。它们可以是嵌入模型权重的对齐，加上输入和输出检查，以及对智能体操作的限制。
模型级别的对齐通常由提供者处理（仇恨、自残、毒性等）
输入护栏会在不需要的消息到达AI代理之前将其阻止：-增强审核加上越狱/SQL注入过滤器-主题限制（无不相关问题、无关于竞争对手的评论、无**或宗教）-业务规则（无PII钓鱼、无内幕信息探测）
运行时护栏会监视AI代理即将执行的操作：–按用户角色限制工具–高风险操作需要人工批准–如果支出、令牌数量或时间超出限制，则终止开关
输出护栏会在输出过程中捕捉到失误：-验证预期的输出模式-Hellucination检查（RAG设置中的源文档验证）-最终内容审核检查
您可以混合使用基于LLM的检查、启发式规则（正则表达式、允许列表）和第三方审核API。选择适合您预算和风险状况的组合。此外，还有几种现成的工具可供使用，例如Guardrails.ai或NemoGuardrails。
2.可观察性
AI代理系统是非确定性的，包含循环，并且可能由于难以识别的原因而失败。如果您使用框架，有时一小段代码（比如二十行代码）就可能触发数十个底层LLM调用或工具调用。可观察性就像一盏手电筒，让您能够看到这些隐藏层的内部，从而理解、排除故障并稳步改进系统。那么，您需要“观察”什么呢？
说明和消息，尤其是模板化的说明和消息。
每个步骤的输入和输出，甚至是用户从未见过的。
AI代理人采取了哪个分支以及为什么。
推理循环——我们真的在朝着目标前进吗？
工具调用、传递的参数和原始结果。
对于RAG设置，返回精确的块和分数。
经典应用程序指标：延迟、错误率、每次运行成本等。
对于我们许多人来说幸运的是，有几个开源可观察性库支持AI代理系统，因此无需手工制作这些日志。
PydanticLogfire：最少关注LLM、数据库、Web框架的可观察性。
Mlflow、ArizePhoenix、WeightsandBiases：它们也具有传统的机器学习操作支持。
Langsmith、Langtrace：专用于GenAI应用程序。
您还可以在可观察性数据之上分层更高级别的功能，例如，对用户交互运行情绪分析或使用单独的AI代理系统来评估生产跟踪以查找失败原因。
3.评估
开发传统的机器学习模型需要验证集和测试集；开发经典软件则需要单元测试和集成测试。AI代理系统则借鉴了这两个阵营。你需要数值和清晰的通过/失败信号，但这些数值并非那么容易获得。你将在没有明确标准的情况下评判一段生成的文本。你将评估AI代理决定采取的路径，而实际上并没有正确的路径。AI代理系统并非一个产生单一输出的单一模型。它包含路由、检索、生成、工具使用、推理链，以及将它们连接在一起的完整循环。你必须同时测试各个部分和整体。
虽然指标仍在不断发展，但这些核心检查已经可以帮你走很远：
端到端的成功：它是否真正完成了用户要求的工作？
轨迹和工具使用：它是否选择了正确的分支并传递了正确的参数？
检索质量：对于RAG，检索是否以适当的精度和召回率返回了您关心的针头？
答案质量：一旦了解背景，最终的回答是否能够回答问题而不是编造事实？
推理痕迹：策划和思考是否揭示了逻辑在哪里脱轨？
多轮评估：经过五六次反复后，对话是否仍然有意义？
成本、延迟、代币销毁：应用程序级健康检查。
为了获得这些方面的分数，你可以结合使用LLM-as-judge（自动化）和人工评估（资源密集型）。在构建评估集时，你可以：
使用LLM合成数据：快速且便宜，但可能与真实用户查询不符。
从遗留日志中引导：您正在替换的系统中旧查询提供了良好的开端。
真实用户样本：收集成本高，但最有效。
制造边缘情况：手工制作您希望永远不会发生的奇怪的角落输入。
生产后果：系统上线后，每次运行失败或用户投诉都会成为需要添加的新案例。
每次调整提示或添加工具时，都要进行评估。快速、可重复的评估可以将“希望它能正常工作”变成真正的工程循环。您可以及早发现隐藏的错误，保持支出可预测，并每天发布安全的更新，而不是每季度一次孤注一掷。RAGAS、Trulens或Mlflow评估都是不错的评估起点。
4.安全
AI代理系统继承了服务面临的所有安全难题，例如令牌泄露或角色权限过高，并添加了几个新的安全问题。AI代理是一个推理引擎，可能会被诱骗运行命令、泄露数据或将控制权移交给另一个AI代理。它还可能启动新的子进程或调用规范中未列出的API。像MCP（模型上下文协议）这样的协议赋予了它们超强的能力，但每个额外的插件都意味着需要守护的另一扇门。至少，最好从所有标准最佳实践开始：将机密放入保管库、授予最小权限以及轮换密钥。此外：
设置防护栏以防止提示攻击，并将所有检索到的文本视为不受信任的输入并扫描对抗模式。
确保AI代理严格在用户权限范围内运行。每次工具调用都应携带用户的访问令牌，以确保其不会接触其他用户的数据。
将每个合作AI代理视为陌生人，并要求其提供与人工呼叫者相同的身份证明。
在沙箱内运行AI代理，除非您明确授予权限，否则沙箱开始时没有网络和磁盘访问权限。
验证MCP边界处的每个输入和输出并对解释器进行沙盒处理。
简而言之，永远不要相信AI代理能够自我监管——用授权检查、日志记录和自动撤销来包装每个决策点。
5.部署
AI代理系统可以通过几种常见的方式部署。一种是通过API调用或计时器触发的短生命周期无服务器函数。例如，AI代理工作流会仔细检查公司收件箱，并将结构化洞察放入表中。另一种是长期运行的有状态服务或微服务，当AI代理必须记住它在多个轮次之间中断的位置或等待人工反馈时，这种服务非常有用。
问题在于运行时间：它们可能耗时几分钟甚至几小时。长时间保持HTTP套接字打开非常痛苦。因此，异步事件驱动的设置更合适。将工作推送到消息队列，让客户端轮询状态端点或监听Webhook，这样就无需再维护连接了。我们还看到多种协议正在尝试标准化AI代理调用工具或共享上下文的方式，例如MCP和A2A（AI代理到AI代理）。值得密切关注它们的发展。
6.身份与持久性
如今，大多数AI代理本质上仍然是无状态的。更改提示或模型，从技术上讲，您就创建了一个新的AI代理。如果没有完整的聊天记录和会话数据，昨天那个乐于助人的助手就像一个陌生人一样对待用户。这种失忆会扼杀信任。相反，如果它拥有持久的身份和角色，那么与它的互动就会感觉像是在与同一个实体打交道。这对于商业环境中的审计目的也很重要。
如果我们不更新LLM权重，身份信息将通过存储在其他地方的数据保留下来。将对话轮次和工具I/O存储在关系数据库或图数据库中。将大型数据放在磁盘或Blob存储中。将语义上可搜索的上下文保存在向量数据库中。为了防止内存爆炸，请将长线索提炼成简短的摘要，并仅保留要点。
六小结
到目前为止，我们所涵盖的所有内容都只是一个更长故事的开端。我们勾勒出了核心部分——工作流、AI代理、护栏、可观察性、评估、安全、部署和身份，但每个主题都隐藏着完整的子学科。我们甚至还没有开始探讨诸如AI代理的运行模式（人机交互还是后台），或者应该使用100多个AI代理框架中的哪一个或者是否需要某个框架之类的问题。构建AI代理系统没有单一的“正确”方案。只有模式、权衡利弊，以及一套快速发展的社区最佳实践。我希望这篇导览至少能勾勒出一些基础知识，以便您知道从哪里开始深入研究。
本文来自微信公众号“数据驱动智能”（ID：Data_0101），作者：晓晓，经授权发布。
