Signature主页

Agent学习记录-2

阅读学习时间：约10分钟

笔记

学习
  • Agent
  • 人工智能

Agent的学习记录--2

来源Github的学习指南Agent Learning Hub的学习：

Stage 0

常用概念区分

  • Chatbot: 其核心定义为人机对话单轮或者多轮的交互前端，其输入是提示词，输出为文本，由机器的自主权或者决策权无，为被动响应，其典型的应用场景为一个客服回答和信息查询。其本质为交互层（interface），其调用基础的LLM或者规则库进行回复，没有“执行长程目标”的概念，缺乏自主拆解复杂多步骤任务、持续调整方向的能力。

  • Workflow: 其是由用户预定义的确定性流程图，其是输入人类预设的有向无环图DAG得以实现，其自主权或决策权很低，典型的应用场景为自动化发票报销、数据 ETL等，其本质是一个确定性管线，由人类工程师预先绘制好节点（例如：第一步搜索资料，第二步总结，第三步如果字数超过500则截断，否则发邮件），其好处在于确定性强、可控度高。虽然节点内可以调用 LLM 处理语义，但节点之间的跳转逻辑完全由代码固化。

  • Agent: 其具备自主规划、工具调用和反思能力的智能体，其自主权或决策权高，其控制流机制为模型主导的感知-决策-行动循环 (ReAct)，其典型的应用场景为自主代码调试、全自动行业调研，由一个公式 Agent = LLM (思考/规划大脑) + Memory (记忆) + Tools (工具调用) + Action (行动)， 其关键特性在于在给定终极目标后，Agent 会自主推导执行路径。如果调用工具失败，它能够读取报错信息并自我修正，直到完成目标。其确定性就不如Workflow。

  • Multi-agent: 其核心定义为多个独立 Agent 组成的协作网络，其自主权或决策权很高，为群体协同，其控制流机制为在单一Agent的基础上进行分布式协作、协商、角色博弈，其典型应用场景为软件开发团队模拟（产品+架构+测试），其类似于公司的架构，不同部门由不同的角色分工与组织架构（Organization）。多个 Agent 各自拥有特定的 System Prompt、上下文和专属工具，通过互相通信、协作或评审来完成单一 Agent 难以处理的大型工程。可以理解为并联的多个Agent。其优势在于避免单个上下文窗口被杂乱信息挤爆，还可以模拟现实组织的分工，比如一个执行者和一个监督者，可以减少模型的幻觉。

  • Subagent: 其为主Agent在执行复杂任务时分发衍生出的子任务单元，其局部自主（但受主 Agent 管控），其由上游的Agent所操控，为典型的树状分层委托，其与Multi-agent的区别在于Multi-Agent 强调的是平级或网状的协作体系；而 Sub-Agent 是纵向层级派生（Parent-Child）。其运作机制为主 Agent（Manager）接管总目标，发现某一块任务耗时或 context 过重，便临时派生或调用一个专用 Sub-Agent（如“代码审查子 Agent”），Sub-Agent 在沙箱中跑完后只将结构化结果汇报给主 Agent。

Multi-agent是否可以继续给subagent派发任务组成大网络？

这种做法通常为分层多智能体网络（Hierarchical Multi-Agent Architecture）。

  • 树状分层派发：
    • 其顶层的核心Agent负责全局任务的拆解，指派给各个专职的Agent，在专职 Agent 接收到复杂模块时，会进一步进行其那一部分的任务拆解进而派发给更细化的 Sub-agents
  • 并行运行：
    • 没有依赖关系的独立任务同时运行，可以减少时间成本
  • 串行运行：
    • 严格的上下游依赖的任务按序交接

最终产出是各 Agent 分别汇出，还是汇总到一个 Agent 汇出？

在工程落地上，绝大多数成熟系统都会“汇总汇出”，但根据任务性质，存在两种具体模式：

  • 汇总到主控 Agent 统一汇出，其运作方式包括
    • 采用 Central Coordinator或专门的 Integrator Agent
    • 各个 Agent/Sub-agent 完成后，把代码或中间物提交到一个统一的环境，比如共享文件目录、Git 分支
    • 最终的 Coordinator Agent负责校验是否能跑通、接口是否对齐，最后统一打包成一个可以直接运行的项目仓库或一封包含完整部署说明的最终交付物给用户。
  • 通过共享状态库协同，其运行方式为：
    • 让所有 Agent 共同挂载在一个共享沙箱环境（Workspace / Memory Store）上
    • 比如前端 Agent 把文件写进 /frontend，后端 Agent 把文件写进 /backend
    • 最后的“汇出”由一个交付/质检 Agent 发出最后的操作。

Agent基本循环

本质: 基于环境反馈的闭环控制系统，在以大语言模型（LLM）为核心的智能体中，这一循环通常具象化为 ReAct

其基本循环为 Observe →\to Think →\to Act →\to Observe

  1. Observe：首先一开始输入传入的时候进行一个捕获（用户的指令/目标/文本）或者环境产生变化，比如一个定时发送器。然后进行上下文的组装，系统将任务提示词（System Prompt）、短期上下文、长期记忆库（向量数据库检索出的历史数据）以及上一轮对话工具返回的结果打包注入给大模型。
  2. Think：在这个阶段模型首先会思考当前状态与目标的差距来给出下一步的最优解，比如借助外部工具，对于工具的调用，需要在这一步生成调用契约，输出结构化的调用参数，比如Json格式
  3. Act：首先，对于LLM模型而言，其并不具备任何任何操作程序的能力，LLM只可以输入输出文本，所以需要在这一步输出指令文本，然后将控制权交回底部宿主代码，然后触发工具，在运行环境解析模型生成的指令，调用对应的外部系统（如发送 HTTP 请求、查询 SQL 数据库、在Sandbox中运行 Python 或派发子任务给 Sub-agent）。
  4. Observe：工具执行完毕后，环境会截取执行后的真是输出，比如接口返回的Json文本，执行日志等，将上述输出作为“Observation”追加到Agent的对话历史中，在这个循环中，如果行动失败就会将失败记录作为Observation在下一轮循环中进行分析和调整策略。

在这个循环中，需要设置一个退出条件，否则有可能会陷入一个死循环。

  • 目标收敛：模型判断任务已全部完成，主动输出非工具调用的最终文本
  • 步数截断：硬性限制最大执行轮数，防止模型反复重试耗尽 Token 和成本
  • 上下文超限：当累积的 Observation 接近模型窗口上限时，触发总结压缩机制或强制中断
  • 人工介入：遇到高风险操作或重试多次依然卡死时，跳出循环向用户请求确认

主流变体模式

  • ReAct 模式：每走一步前都只思考下一步干什么，适合动态性强、探索性高的任务（如查阅文档并定位 Bug）。
  • Plan-and-Solve 模式：外层先生成一个完整的步骤清单（Todo List），内层循环遍历执行每一个步骤，最后做总结，适合长程、确定性较高的任务。

在现在的Agent过程中，还会经常听到一些话术：

  • IR：全称为Intermediate Representation，其在ReAct架构里在Think末端或Act前端开始，LLM直接输出的往往是非结构化的自然语言或半结构化标记。如果要在机器环境里稳定执行，必须转变为结构化的格式。一般而言是Json文本。在Act的开始的时候，需要调用外部代码读取IR，做反序列化、参数合法性校验，然后将其分发给具体的系统接口去执行。
  • Rendered：在Act一步工具执行完后，其返回的数据往往是未经加工的原始数据，比如几万行的网页HTML、或者一些长文本，这种原始数据在Observation阶段如果一次性导入，首先问题是会很消耗Token，其次长文本的输入会使得上下文窗口变得狭窄，注意力分散的问题，因此需要Rendered进行格式化、清洗、压缩、前端可视化之后再输出，输出的产物为Rendered Context / Rendered Observation。

那么究竟什么时候该用Agent？

我们在前面说过，Agent的自主权或决策权高，这也意味着其带来的不确定性也高了。我们可以根据这个特点来描述一些场景：

  • 执行路径不可预知（非确定性状态机）：即我们无法使用if-else画出所有的可能性，比如我们想搜索一些公开的数据，由于其数据位置未知，需要进行搜索，且格式不一，可能遭遇页面结构变化，需要自主决定搜索词、过滤页面、识别真伪并尝试备用来源等，这些情况下使用Agent会更加合适。这也带来一个问题，我们需要去复核。
  • 多步骤工具联动与动态决策：需要根据上一步的 API 返回结果来决定下一步调用哪个工具
  • 开放式环境交互：比如复杂代码的调试，自动化的网页操作，多文档的穿插关联管理

对于不该使用Agent的场景也很简单，我们考虑到Agent的劣势：比如业务规则高度确定、容错率为零，需要100%的正确率，所以这时候不可以交给Agent进行自行规划，而是一个工作流会更有优势，还有输入输出结构明确的单向处理，比如提取PDF中的固定位置（发票的金额，税率)，这时候直接使用OCR+Workflow会更加方便，且速度更快。比如还有需要快速响应的环境，Agent由于其多轮的推理轮次，一次任务需要消耗大量时间，不适用于快速响应和吞吐的环境，但这也不是100%，随着模型的更新，模型的推理速度和吞吐速度也在更新迭代。

Agent 的核心利弊分析

维度 优势（Pros） 劣势（Cons）
灵活性与泛化 面对未知异常或动态需求无需人工频繁改写规则，具有泛化解决问题的能力 行为难以百分之百约束，可能出现“死循环调用”或过度发散（因此使用AGENT.md进行边界约束也是一个常用的工程化方式）
工程复杂度 前期无需写死详尽的状态转移逻辑，Prompt + Tool Definition 即可启动 难以彻底单元测试与复现（Non-deterministic），Debug 成本高
自动化上限 能真正承担 End-to-End 的复杂开放目标（如自主完成数据挖掘与分析） 调用多次模型与外部 API，Token 消耗高、耗时显著增加
容错机制 遇到报错具备自我修正（Self-Correction）潜力 存在执行非预期指令的高危安全风险，因此需要注意权限问题

在现实工程化场景里，我们更愿意先建立一个Workflow作为骨架，然后在上面的节点处添加Agent（这也即是Hybrid），避免过度的离散和幻觉：

  • 能用代码规则写死的，不要交给 LLM 处理
  • 能用标准 Workflow 串联的，不要让 Agent 自由决定路径
  • 仅在 Workflow 中遇到“路径未知、需要模糊探索与自适应调整”的局部子任务时，嵌入局部 Agent 执行

Building effective agents

  • 建立模块：增强LLM

代理系统的基本构建块是使用增强功能（如检索、工具和记忆）的大型语言模型（LLM）

agent2_augmentedLLM.png

在实施的时候，应该结合我们的具体例子定制这些增强功能，并确保能为LLM提供简单和文档齐全的界面。对于这些增强功能，我们可以使用MCP（Model Context Protocol）使得用户能够通过简单的客户端实现，与不断增长的第三方工具生态系统进行集成。

  • Workflow：提示词链（Prompt Chain）

提示链将任务分解为一系列步骤，每个LLM调用处理前一个调用的输出。可以在这个提示词链上添加任意的程序检查（Gate），确保流程在实现目标的路上。

agent2_promptchain.png

这种工作流适合任务可以轻松且干净地分解为固定子任务的情况。主要目标是通过降低延迟以获得更高的准确性，让每次调用都变得更轻松。比如生成一份文档，并且进行翻译；写出一份代码，并且对代码进行测试。

  • Workflow：路由 （Routing）

路由对输入进行分类，并将其导向到专门的后续任务。这种工作流程允许关注点分离，并且构建更加专业的提示。设想，一个LLM适用于所有输入的提示词显然是不好的，一方面增大了推理难度，更可能出现幻觉；另一方面也更加消耗token，且针对一种输入类型优化可能会影响其他输入的性能。

agent2_routing.png

这个工作流适合复杂任务，当有不同类别更适合单独处理，且分类可以通过大型语言模型或更传统的分类模型/算法准确处理时。这个工作流允许将不同的问题使用分类到不同的LLM模型，比如简单的问题用Token消耗少且快的模型，对于困难的问题，则可以使用思考强度高的模型。

  • Workflow：并行化（Parallelization）

LLM有时候可以同时在一个任务上进行工作，然后将他们的输出进行程序化整合。这个并行化工作流，一是将任务拆分为独立的子任务并行执行，二是可以多次运行同一个任务获得多样化的输出

agent2_parallel.png

这个工作流使用时，当分开的子任务可以并行化以加快速度，或需要多角度或尝试以获得更高置信度时，并行化才有效。对于涉及多重考量的复杂任务，LLM通常在每个考量节点时，独立调用处理表现更好，从而能使具体每个方面能够集中注意力。

  • Workflow：编排-工作者（Orchestrator-workers）

在这种工作时，会有一个编排者（Orchestrator），我们称作中心LLM，其会分解任务并且分发给工作（Worker）LLM，然后聚合他们的结果。

agent2_orchestrator_workers.png

这种工作流适合那些无法预测需要的子任务的复杂任务时运用，比方说，在编码过程中，需要修改的文件数量以及每个文件的修改性质可能取决于具体任务。虽然其在结构上和并行化的工作流很相似，但这种工作流具有更好的灵活性，因为其子任务不是预先定义的，而是由编排者LLM根据具体输入来确定的。

  • Workflow：评估器-优化器（Evaluator-optimizer）

在这种工作流下，一次 LLM 调用生成响应，同时另一次调用提供评估和反馈，形成一个循环。

agent2_evaluator_optimizer.png

这种工作流当我们有明确的评估指标，并且迭代修正能够带来可衡量的价值的时候，十分有效。良好匹配的两个标志是：第一，当人类表达反馈时，LLM 的反应可以明显得到改善；第二，LLM 也可以提供这样的反馈。这有点类似于人类作家在创作一篇文章时可能经历的反复写作的修改过程。

  • Agent

Agent的工作始于人类用户的指令或与其进行的交互式讨论。一旦任务明确，Agent便会独立进行规划和运行，并可能返回给人类用户以获取更多信息或判断。在执行过程中，智能体需要在每个步骤中从环境中获取数据（例如工具调用的结果或代码执行情况），以评估其进度。Agent可以用于处理复杂困难的任务，但实际上他们实施起来十分直接，他们通常只是LLM，使用基于循环环境反馈的工具。因此，清晰、周全地设计工具集及其说明文档至关重要。

agent2_agent.png

对于难以预测或无法预测所需步骤数，且无法预先设定固定路径的开放式问题，可以使用Agent，至于更详情的使用，我们在之前已经说过。

agent2_coding_agent.png

Coding Agent 的高级流程

对于上面这些工作流，其都不是固定的，其可以拿来修改和其他的一些进行结合，但在往上面添加复杂度的时候需要记得，其是否提高了输出质量。

Agent需要的三种类型的工具，工具通过利用底层应用或系统的 API 来扩展代理的能力。

Type Description Examples
数据(Data) 使代理能够获取执行工作流程所需的上下文和信息。 查询事务数据库或CRM等系统，阅读PDF文档，或在网上搜索
行动(Action) 使代理能够与系统交互，采取诸如向数据库添加新信息、更新记录或发送消息等操作。 发送邮件和短信，更新客户关系管理记录，把客服工单交给人工
配器(Orchestration) 代理本身可以作为其他代理的工具 退款代理、研究代理、写作代理
  • Multiagent

一般而言，我们更推荐尽可能最大化一个Agent的能力，更多的Agent可以提供概念的直观分离，但可能会引入额外的复杂性和开销。对于许多复杂的任务，将提示词和工具分配给多个Agent可以提高性能和可拓展性。当我们的Agent已经没有办法遵循复杂的指令或者总是选择错误的工具的时候，我们可能就需要进一步地划分系统同时引入多个Agent。比如说提示词有很多条件描述，然后提示词很难被拓展，这时候就要考虑分割逻辑并且分配给不同的Agent。还有一种情况就是当一个任务依赖多个工具的时候，且这些工具具有相似性或者重叠的地方，这时候如果通过提供描述性名称、清晰的参数和详细的描述来提高工具的清晰度并不能提高性能，则可以使用多个代理。

  • Guardrails，护栏

设计良好的护栏有助于你管理数据隐私风险（例如防止系统提示泄露）或声誉风险（例如，强制执行与品牌一致的行为）。护栏是任何基于 LLM 的部署的关键组成部分，但应与强大的身份验证和授权协议、严格的访问控制和标准软件安全措施相结合。把护栏想象成多层防御机制。虽然单个护栏不太可能提供足够的保护，但多个护栏的组合使用可以增强防御能力。

Guardrails的类型有：

  • 相关性分类器，Relevance classifier：通过标记非主题查询，确保代理回复保持在预期范围内
  • 安全分类器，Safety classifier：检测试图利用系统漏洞的不安全输入（越狱或提示注入）
  • PII过滤器，PII filter：通过审核模型输出中潜在的个人身份信息，防止不必要的个人身份信息（PII）暴露
  • 调节器，Moderation：标记有害或不当的行为（仇恨言论、骚扰、暴力），以维持安全、尊重的互动
  • 工具防护措施，Tool safeguards：根据只读与写权限、可逆性、所需账户权限及财务影响等因素，对每个代理工具的风险进行评估——低、中、高。利用这些风险评级触发自动化操作，比如在执行高风险功能前暂停进行护栏检查，或如有需要时向真人核实
  • 基于规则的保护，Rules-based protections：简单的确定性措施（阻断列表、输入长度限制、正则表达式过滤器）以防止已知威胁，如禁用术语或SQL注入
  • 输出验证，Output validation：通过提示工程和内容检查，确保回应与品牌价值观相符，防止可能损害品牌诚信的输出