Agent 工程化与编排

• MCP 协议的作用（统一工具接入）
• 多 Agent 工具调用的工程化
• 标准化的价值

MCP（Model Context Protocol）是 Anthropic 提出的开放协议，定义 LLM 应用与外部工具/数据源之间的标准化接口（类似 USB-C 之于外设）。工程价值：统一工具接入——一套协议接入多种工具/数据源，Agent 无需为每个工具写私有适配；标准化——工具发现、调用、鉴权、错误处理统一，降低集成成本；可移植——同一套 Agent 可在不同 MCP 服务器间复用工具；生态——MCP 服务器可复用，工具能力共享。在多 Agent 场景，MCP 让各 Agent 以统一方式调用共享工具集，减少重复实现，提升工具调用的可维护性与可观测性。

MCP 的价值是"标准化工具接入层"。它把"工具如何暴露、Agent 如何调用"统一，解决多 Agent 环境下工具重复实现、协议不一致的问题。对工程化是"降本 + 可移植 + 生态复用"。

• A2A 协议的作用（Agent 间互操作）
• 跨厂商互操作
• 标准化 Agent 通信

A2A（Agent-to-Agent）是 Google 提出的开放协议，用于不同厂商的 Agent 之间互操作：定义 Agent 的能力发现、任务委派、消息交换、状态同步等标准。工程价值：跨厂商互操作——不同框架/厂商的 Agent 可互相发现、通信、协作，打破平台锁定；标准化——统一 Agent 间通信协议（任务、状态、结果），降低集成成本；生态——可混用多厂商 Agent 与工具。与 MCP 互补：MCP 解决"Agent 调工具"，A2A 解决"Agent 调 Agent"。在多 Agent 场景引入 A2A 可让异构 Agent 协作。

A2A 的价值是"跨 Agent 的标准化通信"。它让异构、跨厂商 Agent 能协作，是 Agent 互联互通的基础。与 MCP 并列，MCP 管工具、A2A 管 Agent，分别解决"Agent 与外"和"Agent 与 Agent"。

• 三类记忆的定位与用途
• 工程设计（存储、检索、生命周期）
• 相互协作

三类记忆：短期记忆=当前上下文窗口，用于当次推理，会话结束清空，工程设计重点是上下文窗口管理与裁剪（防溢出）、摘要；长期记忆=跨会话持久的知识/事实，存向量库/知识库，支持检索，重点是 embedding、索引、更新与遗忘；情景记忆=具体的过往事件/交互（谁何时做了什么、结果如何），存时间序列或事件库，用于类比与个性化，重点是结构化记录、检索、关联。三者协作：短期记忆承载当前推理，长期记忆提供通用知识，情景记忆提供过往经验。设计上要明确存储介质、检索策略、生命周期（TTL/淘汰）与权限。

三类记忆是"当前、通用、经验"的分层。工程关键是"各司其职 + 生命周期管理"。短期管窗口、长期管知识、情景管经验，配合检索与淘汰，避免记忆膨胀与信息冲突。

• MemGPT/Letta 的分层记忆机制
• 上下文管理（OS 式内存分层）
• 虚拟上下文与自动换页

MemGPT（Letta）借鉴操作系统内存分层思想，把 Agent 记忆分为"主上下文"（当前上下文窗口，类似 RAM）与"外部存储"（长期记忆，类似磁盘），通过"自我编辑"与管理函数实现上下文管理与自动换页：上下文满时，Agent 主动把不重要的信息归档到外部存储（类似换出），需要时再检索加载（换入），从而突破上下文窗口限制。工程价值：长对话/长任务可持续，不丢失早期信息；上下文自动管理，减少人工裁剪；记忆分层的模式可复用。它是"有限上下文 + 无限记忆"的工程化方案。

MemGPT 的价值是"用内存分层突破上下文窗口"。核心是"自动换页 + 自我编辑"，让 Agent 在有限窗口内管理无限记忆。它把 OS 内存管理思想移植到 Agent 记忆，是分层记忆的经典实现。

• FSM 的状态建模
• 状态转移与事件
• 与 LLM 决策结合

用 FSM 建模多步任务：把 Agent 看作有明确状态（如 idle/running/waiting_tool/done/failed）的状态机，每个状态定义可执行的动作与在当前状态下的可选转移；事件（如工具返回、用户输入、超时）触发转移。工程实战：用 FSM 约束 Agent 行为——状态与转移是确定性的骨架，LLM 只在"决策点"选择进入哪条转移，避免 LLM 自由发挥导致失控；非法转移被拦截（如未初始化不能执行）；状态持久化便于恢复。这样把"可控的流程骨架"与"灵活的 LLM 决策"结合，提升可靠性与可观测。

FSM 的价值是"用确定性骨架约束 LLM 灵活性"。它把多步任务的流程固定为状态+转移，LLM 只负责决策，非法状态被拦截。这样既保留 Agent 的智能，又保证流程可控、可恢复、可观测。

• 指标体系（工具成功率、任务完成率、token）
• 评估实现（评测集、统计）
• 指标联动与优化

Agent 评估体系涵盖质量、效率、成本三类指标：工具调用成功率——工具调用成功/总调用，定位工具选择与参数生成问题；任务完成率——任务按验收标准完成的比例，衡量整体能力；token 消耗——每任务/每步 token，衡量成本与效率。构建：用评测集（带标注的用例）跑 Agent，统计各指标；细分维度（按任务类型、工具、模型、Agent）。指标联动：完成率低看工具成功率与错误类型；token 高看上下文与循环。用指标驱动优化（改进工具 schema、提示词、模型、上下文管理），并持续回归。

评估体系是"质量+效率+成本"的三角。工具成功率、完成率、token 分别对应"会调用工具、能完成任务、花多少成本"。关键是多指标联动定位根因，且用评测集可重复测量。

• 各范式的机制差异
• 对比维度（工具频率、失败恢复、token）
• 实测选型方法

各范式差异：ReAct——每步"思考-行动-观察"交错，工具调用频率高、灵活但 token 开销大、易陷入循环；Plan-and-Execute——先立计划再执行，工具调用集中在执行阶段、token 相对省、但计划偏差需重计划；Reflexion——在 ReAct 基础上加反思，失败恢复好但 token 更多；AutoGPT——自主长循环，能力强但 token 开销最大、容易失控。实测对比：在相同评测集上测工具调用频率、失败恢复率、token 消耗、任务完成率、延迟。选型：任务简单低风险→Plan-and-Execute 或单 Agent；需交互多步探索→ReAct；需失败自纠→Reflexion（预算充足时）；自主长任务→AutoGPT（需严格护栏）。用实测数据而非臆断选型。

选型是"能力 × 成本 × 可控"的权衡。ReAct 灵活但费 token，Plan-and-Execute 省但僵，Reflexion 稳但贵，AutoGPT 强但难控。必须在同评测集上实测对比，量化为决策依据。

• 可保存的记忆（事实、偏好、行为）
• 隐私与个性化平衡
• 过期与撤回机制

跨会话记忆应保存：用户明确提供的事实（姓名、偏好、需求）、稳定的偏好（风格、习惯）、可复用的行为模式；不应保存敏感信息（凭证、隐私）或未经同意的数据。平衡个性化与隐私：默认保守——只保存高置信、对个性化有用且用户知情的信息；区分"事实"与"临时"——临时信息不长期保存；分级——敏感信息不存或脱敏。过期：设置 TTL、按相关性与时效淘汰；撤回：用户可随时查看与删除自己的记忆（数据删除权），提供撤回接口。记忆要可审计（记录存了什么、谁能看），隐私权优先于个性化。

平衡的关键是"用户知情 + 最小化 + 可撤回"。保存有价值且用户同意的信息，敏感不存，过期淘汰，可撤回删除。隐私是底线，个性化需在范围内进行。

• 成本指标采集（token、模型、工具）
• 按任务/用户/工具归因
• 监控与告警、优化

Agent Cost 监控：采集每次 LLM 调用（输入/输出 token、模型单价）、工具调用与重试的成本；按维度归因——按任务（每个任务花了多少）、按用户（每个用户/租户花了多少）、按工具（每个工具调用的成本）。工程实战：token 记账 + 成本模型（单价×token）→ 成本报表；按 traceId 关联到任务，按用户/租户打标签；设成本预算与告警（单任务/单用户超限告警）；异常检测（成本突增=循环/上下文膨胀）；成本归因驱动优化（大模型换小模型、上下文精简、缓存）。监控要支持细分与对比，支撑计费与优化。

成本监控的核心是"可采集 + 可归因 + 可告警"。按任务/用户/工具多维归因，让成本"谁在花、花在哪"清晰。成本异常（循环、膨胀）是优化的信号，预算与告警兜底。

• 幻觉检测方法（事实核对、自洽检查）
• 事实一致性评估（引用、证据）
• 评估实现

幻觉检测与事实一致性评估：基于证据的核对（grounding check）——把 Agent 输出中的每个声明与检索证据/知识库比对，判断是否有依据，无依据的声明标记为潜在幻觉；自洽性检查——同一主体在输出中是否前后矛盾（事实一致性）；引用溯源——要求输出标注来源，人工/自动核验引用是否真实支撑结论；置信度阈值——对低置信声明标记不确定。工程方法：LLM-as-Judge 评估（给证据与输出，判断事实一致性）、混合检索证据核对、规则校验（数字、日期、事实库）。评估用带标注的评测集（有多少幻觉、多少事实错误）度量，并持续回归。

幻觉检测的核心是"把输出与证据/事实比对"。基于证据核对（grounding）、自洽检查、引用溯源三种手段互补。评估要量化（幻觉率、事实错误率），用评测集+LLM 判断，持续回归。

• 反思机制（回顾错误、语言化改进）
• 错误恢复应用
• 工程实施与成本控制

反思机制让 Agent 在失败后回顾自己的执行过程，语言化分析错误原因并生成改进策略，再重试。工程价值：错误恢复——失败后不盲目重试，而是基于反思修正策略，提高重试成功率；经验积累——反思结论可沉淀为可复用教训，减少同类错误；目标修正——通过反思发现偏离目标的错误并纠正。实施：在失败/低质量后触发反思节点，生成"错误分析+改进计划"，再进行修改与重试；配循环上限与成本控制，防止无限反思。反思要结合外部反馈（测试、工具结果、校验）而非仅自我感觉。

反思的价值是"把失败转化为改进驱动"。相比盲目重试，反思是有方向的修正。工程上要"反思 + 外部反馈"结合，并设上限与预算，避免反思空转与 token 浪费。

• 计划生成（分解、依赖）
• 执行与偏差监控
• 重计划触发与实施

计划阶段：Agent 把目标分解为可执行步骤（含依赖、预期结果、验收），生成计划；也可用 Plan-and-Execute 模式先计划再执行。执行阶段：监控执行与计划的偏差（步骤失败、结果与预期不符、需求变化）。重计划：当偏差超阈值或出现新信息时，触发重计划——重新评估目标、调整步骤、修正计划，再继续执行。实战要点：计划要结构化（可校验）；偏差检测要明确（预期 vs 实际）；重计划有上限与预算，避免无限重规划；计划与执行结果可记录，供复盘。重计划是"计划失效时的自适应"，保证任务在动态环境完成。

计划与重计划是"先规划 + 动态调整"。计划提供方向，重计划吸收执行反馈与新信息。关键是"偏差检测"触发重计划，且重计划有界，避免计划失效导致空转。

• 实体抽取错误与纠偏
• 图谱更新（增量、合并）
• 图谱失效治理（过期、冲突）

知识图谱作长期记忆：从文本抽取实体与关系，错误不可避免。纠偏：抽取结果经校验（LLM 校验/规则/人工抽检），置信度低的实体标记待确认；冲突实体（同实体不同信息）用合并/仲裁；用户反馈或新证据可纠正错误实体。图谱更新：增量更新（新知识追加）、冲突检测（同实体属性冲突时合并或标记）、版本化。失效治理：过期信息标记失效或删除，按 TTL 与时效性淘汰；被更正的信息保留纠错链；图谱质量监控（孤立实体、错误率）。工程上要"抽取-校验-合并-淘汰"闭环，维护图谱质量。

知识图谱记忆的难点是"抽取错误会污染记忆"。核心是"校验 + 合并 + 淘汰"闭环。低置信标记、冲突仲裁、过期淘汰、纠错链记录，防止错误信息长期固化。

• 攻击面（工具结果、外部文档、多轮上下文、用户输入）
• 对抗性测试方法
• 测试集维护

Agent 对抗性测试覆盖攻击面：用户输入（直接注入、越狱）、工具结果（恶意工具返回注入指令）、外部文档（检索到的文档含注入）、多轮上下文（历史轮次被污染）、系统提示（间接泄露）。测试方法：构造注入 payload（指令覆盖、越狱、角色扮演、间接注入）验证 Agent 是否被诱导执行非预期操作。测试集维护：按攻击面分类维护注入用例库，随新攻击手法更新；自动化回归——每次改造后跑对抗测试集，防引入漏洞；样本标注（是否成功注入）；覆盖真实场景（工具、文档、多轮）。漏检要补样例，形成闭环。

对抗性测试的核心是"覆盖所有输入通道 + 持续维护"。间接注入（工具、文档）是 Agent 特有风险。测试集要结构化、可回归、按攻击面持续更新用例，防止漏洞逃逸。

• 性能指标（延迟、吞吐、并发）
• 压测方法
• 基线建立与优化

Agent 性能基准：延迟（LLM 首 token/完整响应、工具调用、端到端 P50/P95/P99）、吞吐（每秒完成任务数/请求数）、并发（在多少并发下性能稳定）。实战：用代表性任务集压测，控制变量（模型、工具、上下文），记录各段延迟；测并发极限（加压观察延迟上升与错误率）；建立性能基线（版本对比、回归）。优化：定位瓶颈（LLM 调用、工具、检索、队列），用缓存、并行、模型分级、上下文精简降低延迟；用限流与队列保稳定。定期回归，防止性能劣化。

性能基准是"可测量 + 可对比 + 可优化"。延迟/吞吐/并发三指标刻画系统能力，压测建基线，优化用瓶颈定位。控制变量与回归让性能可追踪。

• 各基准的领域侧重与成功判定
• 差异分析
• 企业选型取舍

各基准侧重点：GAIA——通用助手任务（真实世界问答、多步推理），成功判定为答案精确匹配，考察通用能力与工具使用；SWE-bench——软件开发（修复真实 GitHub issue），判定为生成的补丁能否通过测试，考察代码能力；τ-bench——工具调用/业务任务（给定 API 集完成业务），判定为是否达成业务目标，考察工具调用可靠性；AgentBench——多场景综合（操作系统、架构、游戏等），判定为任务完成度，考察综合 Agent 能力。企业选型取舍：按业务场景选——做客服选 GAIA/τ-bench，做代码类选 SWE-bench，综合选 AgentBench；同时要建自己的业务评测集（真实数据），因为公开基准与业务场景有偏差。成功判定要与业务目标对齐（端到端成功 vs 单步指标）。

不同基准评测"不同能力"。企业选型要"按业务场景匹配 + 自建评测集"——公开基准用于横向对比，业务评测用于真实验收。成功判定要与业务目标对齐，避免基准高分但业务不给力。

• 各产品的模式（浏览器/计算机操作、通用 Agent）
• 工程价值（自动化、人机协同）
• 落地方案

三者代表不同 Agent 形态：OpenAI Operator——浏览器操作 Agent，通过视觉+操作控制浏览器完成任务（搜索、填表、下单），工程价值是"老化流程自动化"；Anthropic Computer Use——计算机通用操作（屏幕、键盘、鼠标），工程价值是"跨应用操作"的场景自动化；Manus AI Agent——通用任务型 Agent，自主规划执行多步任务，工程价值是"端到端任务自动化"。共性工程价值：把"人操作软件"转化为"Agent 操作软件"，实现流程自动化与人机协同；把 Agent 能力封装为可监控、可审批、可回退的产品。落地要关注安全（权限、审批）、可观测、失败兜底。

三者是把"操作能力"Agent 化的代表。工程价值在于"自动化 + 人机协同"，但都面临"不可逆操作需审批、可观测、失败兜底"的工程挑战。落地要对高风险操作设审批与回退。

• 各追踪平台的能力
• 多 Agent trace 的价值
• 观测、评测与调优

追踪平台（LangSmith、Langfuse、Helicone、LangWatch）提供 Agent 的 trace 观测：记录每次 LLM 调用、工具调用、Agent 步骤、token、延迟、成本；按 traceId 聚合调用链；支持检索、回放、评估（LLM-as-Judge）、A/B 对比、告警。工程价值：可观测——多 Agent 复杂流程可视化，定位问题；可评测——对 trace 做评估与回归；可调优——分析 token/延迟/错误，优化提示词、模型、上下文；可审计——记录决策过程。LangSmith 生态好、Langfuse 开源可自托管、Helicone 专注成本代理、LangWatch 侧重安全与监测。选型看部署、成本与生态。

Trace 平台的价值是"让多 Agent 复杂流程可观测、可评测、可调优"。统一采集、聚合、评估是 Agent 工程化的基础设施。选型权衡开源/托管、成本、生态。

• 各框架的定位与机制
• 多 Agent 能力差异
• 选型建议

三框架对比：OpenAI Swarm——轻量的多 Agent 编排框架（handoff、函数调用），强调简单、教育性，适合轻量多 Agent 原型，但非生产级（无内建持久化/日志）。AG2（原 AutoGen）——微软多 Agent 对话框架，支持群聊、多 Agent 协作、代码执行、工具，功能丰富、可扩展，适合较复杂多 Agent 应用，但学习曲线较高。Semantic Kernel Agents——微软 SDK，基于 .NET/Python，与 Azure 生态集成，支持 Agent、插件、记忆，适合企业级与 .NET 栈，多 Agent 支持较新。选型：轻量原型用 Swarm，复杂协作用 AG2，企业 .NET/Azure 用 Semantic Kernel。结合任务复杂度、生态、语言栈选择。

框架对比维度是"复杂度 × 生态 × 语言栈"。Swarm 轻、AG2 强、Semantic Kernel 企业级。没有万能框架，选型要匹配任务复杂度与团队栈，并考虑生产就绪度（持久化、可观测）。

• 各框架的记忆能力
• 存储与检索机制
• 选型建议

专用记忆框架对比：Mem0——面向 Agent 的长期记忆，从对话提取事实与偏好，自动抽取、更新、检索，可跨会话，支持向量+知识整合；Zep——面向对话的长期记忆，提供记忆提取、语义检索、时间感知，适合会话型应用，开源可自托管；LangMem——LangChain 生态的记忆工具，支持记忆管理与持久化，与 LangGraph 集成。对比维度：抽取能力（自动提取事实）、存储（向量/图）、检索（语义/时间）、集成（框架生态）、部署（托管/自托管）。选型：用 LangChain 生态选 LangMem，会话型选 Zep，通用 Agent 长期记忆选 Mem0。结合抽取质量、检索与生态。

记忆框架差异在"抽取质量 + 存储 + 检索 + 生态"。选型关键看是否需要"自动抽取事实"、检索方式、与现有框架的集成，以及自托管 vs 托管。记忆质量要实测（抽取准确率、检索召回）。

• 各框架的定位与机制
• 代码能力与工具
• 选型建议

Coding Agent 框架对比：OpenHands（原 OpenDevin）——自主编码 Agent，可操作完整的开发环境（文件、终端、执行测试），自主完成多步编码任务，适合复杂任务；Cline——IDE 插件型编码 Agent，在 VS Code 中操作文件、终端、调用模型，适合交互式辅助编码，部署简单；Continue——IDE 扩展，侧重代码补全、对话式编码辅助，轻量。对比维度：自主性（自主 vs 交互）、环境操作（文件/终端/浏览器）、集成方式（CLI/插件）、模型适配。选型：复杂自主任务用 OpenHands，交互辅助用 Cline/Continue。结合任务复杂度与工作流。

编码 Agent 框架差异在"自主性 × 环境操作 × 集成方式"。OpenHands 自主强、Cline/Continue 交互辅助。选型看任务复杂度（自主完成 vs 辅助编码）与开发者工作流。

• 沙箱的作用（隔离执行、安全）
• 各沙箱能力
• 安全与工程价值

Agent 沙箱提供隔离执行环境，让 Agent 运行代码/操作安全可控：E2B——面向 AI 的云沙箱，提供安全的代码执行环境（Python/JS），Agent 可实时运行代码、管理文件，适合工具型 Agent；Modal——云函数/沙箱，提供按需执行 GPU/CPU 环境，适合计算密集任务；Daytona——开发环境沙箱，提供隔离的开发环境。工程价值：安全隔离——Agent 生成的代码/命令在沙箱运行，不污染宿主、防注入与越权；可回收——用完即销毁，无残留；可观测——记录执行过程。沙箱是"Agent 执行不可信代码"的安全边界，价值在于"安全 + 隔离 + 可回收"。

沙箱的价值是"安全隔离 + 可回收"。Agent 生成的代码不可信，必须在隔离环境运行。E2B 面向代码执行、Modal 面向计算、Daytona 面向开发环境，选型看执行类型与安全要求。

• 冷启动与预热的定义
• 预热策略（延迟加载、缓存、会话预建）
• 工程价值

冷启动指 Agent 首次运行/会话建立时的初始化开销（加载模型上下文、工具、索引、建立会话），预热指提前初始化以降低首次延迟。工程价值：降低首延迟——预热加载常用上下文、模型会话、工具索引，避免首次请求慢；资源复用——预热池化复用高频 Agent 实例，减少重复初始化；扩展与弹性——预热使新实例就绪，应对流量。缺点：预热占用资源、维护成本。策略权衡：高频/对延迟敏感→预热（池化、缓存）；低频/稀疏→冷启动即可。预热要结合资源成本与延迟需求，避免过度预热浪费资源。

冷启动与预热是"首次延迟 vs 资源成本"的权衡。预热降低首延迟、复用资源，但占用资源。关键按"频率 × 延迟敏感度"决定：高频延迟敏感预热，低频冷启动。过度预热是浪费。