Agent 开发

一、Agent 开发中的推理循环是如何设计与实现的？ReAct 范式在其中扮演什么角色？

1. 推理循环的基本结构

推理循环是 Agent 在任务执行期间反复进行"思考—行动—观察"的迭代结构，是让 LLM 从静态生成转向动态解决问题的关键机制。其典型运行过程为：接收目标或观测 → LLM 进行推理并决定下一步 → 执行动作获得观测结果 → 将结果纳入上下文继续下一轮，直至任务完成或触发终止条件。

2. ReAct 范式的运作方式

ReAct（Reasoning + Acting）是推理循环最具代表性的范式之一：它要求模型交替生成"推理轨迹（Thought）"与"动作（Action）"，并接收"观察（Observation）"作为下一轮输入，使推理过程可见、可追溯。工程上通常以结构化提示或函数调用实现——模型先输出思考与工具调用请求，运行环境执行工具后将结果回填为观察，再交给模型继续推理。

3. 上下文累积与状态更新

循环的每一轮都会更新 Agent 的上下文，包括历史对话、工具返回与中间结论，使后续决策建立在累积信息之上；这也正是上下文工程需要精细管理的原因。当上下文过长时，需通过摘要、裁剪或外部存储来搬运状态。

4. 反思环节与范式增强

循环中常包含"反思（Reflection）"环节：Agent 对自身输出或工具结果进行评估，若不满足目标则修正计划重新执行。实践中还常对原始 ReAct 做增强，例如加入计划（Plan）、自我批评（Self-Critique）或工具结果缓存，以抑制无效循环并提升复杂任务的成功率。

5. 循环的终止条件

循环必须有终止条件，否则会陷入无限循环并持续消耗成本。常见终止信号包括：模型输出最终答案、连续多轮无新增信息、步数或成本触及预算上限、以及人工中断。Anthropic 在《Building Effective Agents》中将"Agent 由 LLM 在运行时动态指导自身流程与工具使用"作为 Agent 的定义性特征，而"由预定义代码路径编排"则属于 Workflow，二者的分界正在于此。

二、Plan-and-Execute 模式适用于哪些 Agent 开发场景？

1. 模式定义：规划与执行分离

Plan-and-Execute 是一种将"规划"与"执行"分离的 Agent 模式：先由 LLM 生成一份相对完整的任务分解计划，再由执行模块逐步完成各子步骤，必要时再回溯调整。它与纯推理循环的核心差异在于，规划阶段一次成型而非每步重规划。

2. 适用场景

该模式适合目标复杂、步骤多、但单步相对明确的任务，例如调研报告生成、数据分析流水线、跨系统工单处理等，可减少在每一步都重新规划带来的 Token 浪费与延迟累积。

3. 相对于纯推理循环的优势

相比纯推理循环，其优势在于成本控制与结果可预测性——执行阶段可复用同一计划，计划树本身也可作为可观测与可回滚的对象；但当环境剧烈变化、原定计划失效时，需要重新规划或引入人工介入，灵活性相应下降。

4. 工程实现方式

在工程实现上，计划常以结构化列表或图结构存储，由编排器逐条调用工具并回填结果，逐步校验计划项是否达成，必要时触发重规划。

三、Agent 开发的完整生命周期包含哪些阶段？

1. 需求定义

明确用例、目标、输入输出、成功指标、自主度边界与需人工审批的动作，这是后续一切工作的基准，也是评估集设计的依据。

2. 架构设计

选择最简可行的架构（单 Agent / RAG / 多 Agent / 工作流），定义推理模式、记忆策略、工具契约与编排方式。

3. 数据与工具集成

连接知识库、数据库、API 与 SaaS，用 RAG 接入企业知识，用 MCP 等标准接入工具，并严格控制访问权限。

4. 原型构建

以最小可用版本跑通目标流程，先验证功能正确性，再逐步叠加能力。

5. 评估评测

用真实场景评测集检验任务完成率、工具准确率、幻觉、成本与升级行为，并将评测左移到开发期，避免上线后才发现质量问题。

6. 安全与治理

上线前落实权限、审计、提示注入防护与人工介入（HITL），并对高影响动作设置审批或回退路径。

7. 部署与观测

以影子模式、灰度发布、版本回滚等方式上线，建立追踪、成本、延迟与结果的持续监控。

8. 持续迭代与 ADLC

持续迭代环节用生产证据（追踪、反馈、业务结果）反哺评测集与提示 / 工具 / 检索优化，形成"定义—构建—评测—部署—优化"的闭环。业界也将其概括为 ADLC（Agent Development Lifecycle），即构建—测试—部署—监控四阶段循环，由 LangChain 团队于 2026 年 5 月形式化，其核心是让生产追踪（带裁决标签）回流为下一轮构建的评测用例。

四、Agent 开发中的上下文工程包含哪些核心内容？

1. 上下文工程的定义

上下文工程是指在大模型推理过程中，系统性地筛选、组织与维护"模型每一步应当看到的最优 Token 集合"的一整套策略。Anthropic 的应用 AI 团队于 2025 年 9 月正式提出并定义该术语，定义为"在大模型推理过程中策展并维持最优 Token（信息）集合的策略集，包括提示之外可能落入上下文的其他所有信息"。

2. 与提示词工程的区别

与提示词工程关注"如何措辞提问"不同，上下文工程关注"Agent 究竟看到了什么信息"，涵盖系统指令、记忆、检索结果、工具定义与历史对话的组织方式。Anthropic 将前者视为后者的一个子集——提示词工程是上下文工程的一个组成部分，而非替代。

3. 对表现与成本的决定性影响

它直接决定 Agent 的表现与成本：冗余或混乱的上下文会拖慢推理、推高 Token 消耗并引发"上下文腐烂（Context Rot）"——模型召回准确率随 Token 数上升而下降，且该现象跨模型普遍存在。更强的模型能处理更长上下文，但这只是把"墙"往外挪，不会消除问题。

4. 典型实践手段

典型实践包括：稳定前缀置顶（系统提示与工具定义放最前以命中缓存）、渐进式工具发现（只向模型暴露相关工具）、动态裁剪历史、分段摘要（Compaction）、结构化笔记外置到文件，以及按需加载指令模块；压缩应在上下文接近阈值时主动触发，例如 Claude Code 在占用约 95% 时启动自动压缩。

5. 核心操作分类

核心操作可归纳为四类：卸载（Offloading，把信息移到外部系统）、约简（Reduction，压缩或摘要陈旧信息）、检索（Retrieval，相关信息出现时才拉取）、即时加载（Just-in-time Loading，只存轻量标识、按需取全量）。判断上下文是否健康的实践标准是：若你无法判断一个正确结果"应该长什么样"，则 Agent 很可能也无法稳定做到。

五、Agent 开发中的短期记忆与长期记忆分别如何实现？

1. 短期记忆的实现

短期记忆指 Agent 在单次会话或任务进行中的上下文窗口内容，包含对话历史、中间推理与工具结果，随任务结束而自然消失。管理短期记忆的关键在于上下文工程：通过滑动窗口、分段摘要、重要性标记等手段，在上下文超限前主动压缩或遗忘低价值信息。

2. 长期记忆的实现

长期记忆指跨会话持久化的知识与状态，通常存储在外部系统（如向量数据库、键值存储、知识图谱），用于让 Agent "记住"历史经验或企业私域知识。

3. 检索与写入策略

管理长期记忆的关键在于检索与写入策略：将文档切片向量化后存入向量数据库以支持 RAG 检索，同时设计写入时机、去重与更新机制，避免记忆陈旧或冲突。

4. 上下文污染：被忽略的失效模式

一个常被忽略的失效模式是"上下文污染"：Agent 读取了过期或错误的信息（如工具返回的旧状态），并据此采取行动。长期记忆的写入应当带置信度与时效标记，读出时能判断新鲜度，否则记忆越多反而越容易误导。

六、Agent 开发中的工具调用机制是如何实现的？

1. 工具 Schema 的依赖

工具调用依赖"工具 Schema"：开发者为每个工具提供名称（须匹配 ^[a-zA-Z0-9_-]{1,64}$）、功能描述、输入参数（JSON Schema），模型据此理解可用能力。

2. 工具调用的运行流程

运行流程为：模型根据目标与上下文判断是否需外部信息或动作 → 输出结构化工具调用请求（含参数） → 执行环境调用真实工具 → 将结果以"观察"形式回填上下文 → 模型基于结果继续推理直至给出最终答复。

3. 上下文消耗与优化手段

工具定义本身会消耗上下文，且数量过多会显著降低选择准确率。实践中的有效手段包括：工具搜索与渐进式发现（按需加载而非全量注入）、程序化工具调用（让模型写代码解析大体积返回结果）、以及为复杂工具提供示例输入（Tool Use Examples）。

4. 返回信息的高信号设计

由于工具返回结果往往占据大量上下文，工程上应让工具只返回高信号信息：返回语义化、稳定的标识符（如 slug、UUID）而非不透明的内部引用，并且只包含模型推理下一步真正需要的字段。

七、MCP 协议在 Agent 开发中解决了什么问题？

1. 协议定位与开源背景

模型上下文协议（Model Context Protocol，MCP）是一个开放的 Agent 与工具连接标准，由 Anthropic 于 2024 年 11 月开源，采用 JSON-RPC 2.0 通信。

2. 解决工具集成的碎片化

它要解决的问题是"工具集成的碎片化"：在 MCP 出现前，每个 Agent 需为不同数据源、API 单独编写适配代码；MCP 提供统一接口，让工具一次开发即可被任意兼容客户端复用。

3. 三大原语

MCP 定义三大原语：tools（供模型调用的可执行能力）、resources（可供读取的上下文数据）、prompts（可复用的提示模板），形成 agent-to-tool 的标准连接层。Anthropic 亦将其列为增强型 LLM 三项能力（检索、工具、记忆）的推荐实现路径之一。

4. 生态与治理现状

生态与治理方面，MCP 于 2025 年 12 月捐赠至 Linux 基金会 Agentic AI Foundation（与 OpenAI 的 AGENTS.md、Block 的 goose 同为创始项目）；据 2026 年 3 月数据，其月度 SDK 下载量已达 9700 万，活跃服务器数量超过 1 万个，客户端覆盖 ChatGPT、Claude、Cursor、Gemini、Microsoft Copilot、VS Code 等主流平台，已成为 Agent 工具集成的主流协议之一。

八、A2A 协议在 Agent 开发中承担什么角色？

1. 协议定位与开源背景

智能体间通信协议（Agent2Agent Protocol，A2A）是一个面向 Agent 之间协作的开放标准，由 Google 于 2025 年 4 月发布，并交由 Linux 基金会托管。

2. v1.0 稳定版与核心机制

2026 年 4 月 9 日，A2A 发布 v1.0 稳定版，已有 150 多个组织参与、超过 22000 个 GitHub stars，并引入 Signed Agent Cards（以加密方式验证 Agent 身份与能力声明）、企业级多租户隔离与 Agent Payments Protocol（AP2）等机制，同时提供 Python、JavaScript、Java、Go、.NET 五种语言的 SDK。

3. 与 MCP 的定位互补

与 MCP 的定位互补：MCP 解决 agent-to-tool（智能体连接工具与数据），A2A 解决 agent-to-agent（智能体彼此发现、委派与协作），二者共同构成 Agent 时代的"双栈"互联基础。Linux 基金会在公告中亦明确将 A2A 描述为与 MCP 互补。

4. 实践中的组合方式

实践中常见的组合是：用 A2A 在多个厂商 / 团队的 Agent 间建立协作网络，而每个 Agent 内部再通过 MCP 接入自己的工具与知识源，从而实现跨组织、跨系统的智能体协同。微软已将其集成进 Azure AI Foundry 与 Copilot Studio，AWS 则通过 Amazon Bedrock AgentCore Runtime 支持。

九、Agent 开发中的多智能体编排有哪些主流模式？

1. 多智能体编排的定义与价值

多智能体编排是指让多个各具专长的 Agent 协同完成复杂任务的设计方法，相较单一 Agent，它在分工、并行与专业化上更具优势，但同时增加协调成本与调试难度。

2. 主管—下属（Supervisor）模式

主管—下属（Supervisor / Manager）模式由一个主 Agent 负责拆解任务并分派给专家子 Agent，汇总结果后交付。需要区分的是，若分派规则由代码预先固定（如"账单问题分给 A、技术问题分给 B"），本质是 Workflow 的路由模式；只有当主 Agent 在运行时动态决定如何拆分任务，才属于真正的编排者—工作者模式。

3. 编排者—工作者（Orchestrator-Workers）模式

编排者—工作者（Orchestrator-Workers）模式由编排者在运行时动态拆解任务并分配，工作者并行完成后回传，适合任务结构在运行时才明确的场景。

4. 群聊 / 辩论（GroupChat / Debate）模式

群聊 / 辩论（GroupChat / Debate）模式让多个 Agent 通过自然语言多轮协商达成共识，适合研究性、创意性或需反复讨论的任务。

5. 评估者—优化者（Evaluator-Optimizer）模式

评估者—优化者（Evaluator-Optimizer）模式由一个 Agent 生成结果，另一个 Agent 对其评估并给出改进建议，形成质量闭环，常用于写作或代码生成。

6. 被忽视的工程约束：子 Agent 的历史隔离

一个常被忽视的工程约束是：子 Agent 不继承主 Agent 的对话历史，因此主 Agent 必须在任务描述中显式传递子 Agent 所需的全部事实，否则子 Agent 会在信息缺失下返工。

十、Agent 开发中的状态管理与持久化如何设计？

1. 状态管理的基本定义

状态管理是指 Agent 在长流程、多步骤或异常中断时，仍能准确保持与恢复执行进度的能力，是可靠 Agent 的工程基石。

2. 单 Agent 场景的状态搬运

在单 Agent 场景下，状态体现为不断增长的上下文；当上下文过长时，通过摘要、压缩或外部存储来"搬运"状态，避免丢失关键约束与用户需求。

3. 图式编排框架中的状态持久化

在图式编排框架（如 LangGraph）中，状态以有向图节点间传递的结构化对象存在，并借助检查点（Checkpointer）持久化，从而支持断点续跑与"时间旅行"式调试。

4. 分布式与多智能体场景的状态传递

在分布式或多智能体场景下，状态需在进程间传递，常借助 W3C TraceContext（traceparent / tracestate）等标准将追踪上下文随消息一并序列化，保证跨进程可追溯。

十一、Agent 开发如何界定能力边界与自主度？

1. 典型的 Agent 系统组件构成

一个典型的 Agent 系统由若干职责清晰的组件构成：规划模块（Planner）负责将目标拆解为子任务或生成执行计划；记忆模块（Memory）分为会话内的短期记忆与外部持久化的长期记忆；工具与接口层（Tools / Actions）让 Agent 能调用 API、查询数据库与检索知识；模型推理核心（LLM Core）承担理解、推理与决策；编排与状态管理协调流程、保存检查点；安全与治理层包含权限控制、提示注入防护、人工介入、审计与可观测性。其中"增强型 LLM"（Augmented LLM）即检索、工具、记忆三项能力叠加于基础模型之上，是最小的可运行单元。

2. 能力边界的界定原则

界定能力边界要回答"这个 Agent 到底该不该做这件事"。Anthropic 在《Building Effective Agents》中建议先找最简单的可行方案，只在必要时才增加复杂度——"这甚至可能意味着完全不构建智能体系统"，因为很多被称为 Agent 问题的需求，其实只是一次调用 LLM 加上检索与上下文示例即可解决。

3. 自主度的二维分级

自主度应按"错误代价 × 路径可预测性"两个维度分级：若流程能在白板上画出每一步分支，用工作流即可；若下一步取决于模型当下的发现，才需要 Agent。错误代价高的环节（资金、对外发送、生产数据删除）应用固定代码加人工审批兜住。判断的核心是两个问题：出错代价有多高（低意味着错了只浪费一小时，高意味着客户、付款、合同或监管会看到），以及路径是否可预测（输入相似、步骤可枚举为可预测；每个案例步骤数与顺序都不同则为不可预测）。两者组合可得决策矩阵：可预测加低代价用工作流，不可预测加低代价可用 Agent，可预测加高代价用工作流并在不可逆步骤前加人工确认，不可预测加高代价则拆分为混合方案——把不确定性交给 Agent，把风险固定为代码。

4. 立项阶段的三类清单

在立项阶段就应明确写出三类清单：Agent 允许做什么、明确禁止做什么、什么情况必须交回人类。这份清单比任何提示词都更能决定 Agent 的实际行为边界。

十二、Agent 开发选择推理模型时需要评估哪些因素？

1. 核心评估因素

模型选型直接决定 Agent 产出的质量、速度与成本，应尽早评估。核心评估因素包括：任务类型与复杂度、响应可接受的准确率门槛、延迟目标（常以分位数指标衡量，例如 P95 响应时间）、请求量级、错误后果的业务风险，以及部署约束（是否需私有化、本地处理或特定合规要求）。

2. 能力与成本的正相关

能力与成本呈正相关：更强模型延迟更高、成本更高，但幻觉风险更低；小模型响应快、成本低，但在复杂逻辑与专业任务上表现下降。据此可建立分层用能策略——分类、路由、关键词抽取、结构化输出等窄任务交小模型，多步推理、歧义输入解析、需判断力的综合任务交前沿模型。

3. 端到端延迟与成本归因

端到端延迟需按完整工作流衡量，而非单次模型调用：路由时间 + 关键路径模型时间 + 工具执行时间 + 校验时间 + 重试时间。同理，成本核算通常建议按"每次成功任务"而非"每次请求"归因（这是工程实践中常见的成本归因口径），因为单次调用便宜并不等于整个工作流便宜——重试与升级会抵消价差。

4. 分层用能的实践路径

实践路径是先用高能力模型建立性能基线并验证用例，再逐步用轻量模型替换并对比质量、总成本、延迟、重试率与工具调用正确率，直到找到满足质量门槛的最低成本配置；模型可替换性应作为架构设计目标保留，而非在实现时写死。

十三、Agent 开发如何设计工具的描述与输入输出契约？

1. 工具描述：性能的关键单一因素

工具描述是影响工具调用性能最重要的单一因素。描述应当说明：这个工具做什么、什么情况下该用、什么情况下不该用、每个参数的含义及其如何影响工具行为、以及重要限制（例如工具不返回什么信息）。Anthropic 建议非复杂工具的描述也至少写 3~4 句，复杂工具则应更长。

2. 输入契约与示例

输入契约使用 JSON Schema 表达。对于嵌套对象、可选参数众多、或对格式敏感的工具，仅靠 Schema 不足以让模型正确调用，此时应补充示例输入（Anthropic 的 Tool Use Examples）——Anthropic 内部测试显示，示例可将复杂参数处理的准确率从 72% 提升至 90%。由于示例会增加 Token 开销，这一手段应按需使用而非全量铺开。

3. 输出契约的高信号原则

输出契约的设计目标是"只返回高信号信息"：返回语义化、稳定的标识符而非不透明内部引用，只包含模型推理下一步所需字段，避免臃肿返回体挤占上下文。

4. 减少工具数量与选择歧义

减少工具数量与选择歧义同样关键：将相关操作合并为单一带动作参数的工具，而非为每个动作各建一个；工具跨多服务时用服务名前缀做命名空间（如 github_list_prs、slack_send_message），使选择无歧义，尤其在启用工具搜索时更为必要。此外，工具数量本身存在上限约束，业界普遍建议将活跃工具控制在个位数到十余个以内（Anthropic 亦主张 fewer, more capable tools），过多会降低选择准确率。

十四、Agent 开发中的错误处理与重试机制如何设计？

1. 工具调用失败处理

对超时、返回异常或格式错误的工具结果，采用重试（带退避）、切换到备用接口或返回兜底响应，避免单次失败中断整个任务。

2. 循环与步数熔断

设置最大步数 / 重试上限与电路断路器（Circuit Breaker），在连续失败（如同一工具连续多次失败）时停止运行，防止无限循环烧钱。

3. 计划回退与重规划

当原计划因环境变化失效，Agent 可回到检查点重新规划，或从长期记忆中恢复已有进度继续，而非从零开始。

4. 可观测支撑

将每次失败作为带标签的追踪（Trace）记录，回流到评估集与调试流程，使同类故障在未来被提前识别与修复。

十五、Agent 开发如何防范提示注入攻击？

1. 提示注入的风险定义

提示注入是指攻击者通过 Agent 可接触的外部环境（网页、邮件、文档、工具返回）植入恶意指令，诱导 Agent 偏离既定目标或泄露信息，是 Agent 特有的高危风险。

2. 数据与控制分离

将"系统指令"与"外部输入数据"在提示结构与处理流程上明确隔离，避免不可信内容被当作指令执行。

3. 最小权限与沙箱

限制 Agent 对工具、文件与网络的访问范围，使其在隔离环境中执行，降低注入得手后的破坏面。

4. 输入校验与输出审查

对外部内容进行合法性检查、敏感词与越权动作拦截，并对高风险动作强制人工确认，形成纵深防御。

十六、Agent 开发中的权限控制与最小权限原则如何落地？

1. 最小权限原则的定义

最小权限原则要求每个 Agent 或工具仅拥有完成其职责所必需的最低访问权限，而非无差别地开放全部系统与数据。

2. 工具接入时的权限配置

在工具接入时，应为每个 MCP 工具、API 或数据库账号单独配置权限范围，使"读取订单"的 Agent 无法"改写数据库"、"发送邮件"的 Agent 无法"删除资源"。

3. 结合运行时策略的临时授权

结合运行时策略，可对权限做时间与场景限定，例如仅在特定工作流阶段、仅对特定用户数据授予临时访问，任务结束即回收。

4. 安全治理的黄金三角

该原则与提示注入防护、沙箱共同构成 Agent 安全治理的"黄金三角"，是防止越权与范围蔓延（Scope Creep）的基础。

十七、Agent 开发如何实现人工介入机制？

1. 人工介入（HITL）的定义

人工介入（HITL）指在 Agent 自主运行流程中，为高风险或不可逆动作设置人类审批 / 确认节点，使人在关键决策上"在岗"，而非完全放手。

2. 需要 HITL 的典型环节

需要 HITL 的典型环节包括：资金交易与退款、发送对外邮件或消息、删除 / 修改生产数据、部署代码、以及任何可能造成法律或声誉影响的动作。

3. 两种落地形式

落地形式有"人工确认后执行（Human-in-the-Loop）"与"先自动运行、人仅监控（Human-on-the-Loop）"两种；随 Agent 可靠性提升，可由前者逐步过渡到后者。

4. 在编排框架中的实现

在图式编排框架中，可在任意节点插入人工断点（Interrupt），等待审批后再继续，从而兼顾自动化效率与可控性。审批与编辑结果应回流为评测数据，成为下一轮改进的依据。

十八、Agent 开发中的沙箱执行环境应该如何设计？

1. 为何需要沙箱：风险背景

Agent 常需执行代码、调用系统命令或访问外部网络，若直接在宿主环境运行，一旦被提示注入或逻辑出错，可能造成数据泄露、资源耗尽或系统破坏。

2. 隔离的执行环境

沙箱提供隔离的执行环境：限制文件系统、网络、进程与算力边界，使 Agent 的代码执行"画地为牢"，即使出错也不波及宿主。

3. 资源限额与审计

沙箱还便于做资源限额与审计：对 CPU、内存、运行时长与出站流量设限，并记录全部执行行为，满足合规与溯源要求。

4. 企业级 Agent 治理底座中的沙箱

在企业级 Agent 治理底座中，云沙箱常作为标准组成部分（如腾讯云 ADP 底层 Agent Infra 中的"云沙箱"，与执行引擎、上下文服务、网关、可观测并列），沙箱启动速度与并发扩容能力是衡量其工程水平的关键指标。

十九、Agent 开发的评估体系包含哪些环节？

1. 评估体系的闭环构成

评估体系并非单一环节，而是贯穿需求、设计与上线运营的闭环，通常包含四个环节：目标定义、离线评估、在线评估与回归保障。

2. 目标定义环节

目标定义环节要先把成功指标写清楚，包括任务完成率、工具调用准确率、允许的成本与延迟上限、以及越权与升级行为的发生频率。这一步若跳过，后续所有分数都失去参照。

3. 离线评估与在线评估

离线评估在开发期用固定数据集运行，作为发布门禁，保证"已知场景不退化"；在线评估在生产流量上抽样打分，捕获"未见过的长尾失败"。LangChain 的实践建议是二者必须同时具备：在线评估告诉你昨晚的 helpfulness 是否掉了、某工具是否更频繁地失败；离线评估告诉你提示词改动、模型替换或架构调整是否真的带来改进。

4. 回归保障环节

回归保障环节把生产中出现的失败案例沉淀为评测用例，形成"线上发现 → 进入评测集 → 发布前拦截"的回路。这一机制与 ADLC 中"带裁决标签的追踪回流到下一轮构建"是同一思想的具体落地。

二十、Agent 开发常用的评估指标与评估方法有哪些？

1. 评估应覆盖的三个层次

评估应覆盖三个层次：最终答案（Final-answer，是否正确）、轨迹（Trajectory，步骤与工具调用是否合理）、逐轮（Per-turn，单步是否越权或偏离策略）。仅看最终答案会遗漏过程风险，例如在多智能体场景中，只评最终输出无法发现子 Agent 选择错误、工具顺序颠倒或多余调用。

2. 关键评估指标

关键指标包括：任务完成率 / 成功率（并核验系统真实状态，而非仅文本）、工具调用准确率、步数与循环次数、轨迹匹配度、成本与延迟、以及基于检索的忠实度（Groundedness）。

3. 评估方法与评分手段

评估方法按数据来源分为离线（固定数据集、CI 门禁）与在线（生产流量、实时打分）两类；评分手段包括代码化规则评分、LLM 评委（LLM-as-Judge）、Agent 评委与人工抽检。LLM 评委须先做校准——人工标注真实追踪、运行评委、找出分歧、迭代评委提示词，否则分数看似严谨实则无意义。

4. 常用工具与代表性基准

常用工具可跨框架使用且兼容 OpenTelemetry：LangSmith、Langfuse、Arize Phoenix、Braintrust、DeepEval、OpenAI Evals 等；代表性基准有 GAIA、Tau-bench（会校验数据库真实状态而非仅答案）、SWE-bench、BFCL、OSWorld 等，用于横向衡量不同 Agent 的能力边界。

二十一、Agent 开发中的可观测性需要采集哪些数据？

1. 可观测性的定义与价值

Agent 可观测性是指在不确定的运行行为中，仍能理解"Agent 为何这么做"的能力，是 Agent 工程上线后的"诊断引擎"，区别于传统仅关注延迟与错误率的 APM。

2. 层级化追踪（Trace / Span）

它要求在每次运行中记录层级化追踪（Trace / Span）：从会话根节点，到每一轮用户交互，再到内部的 LLM 调用、工具调用与检索步骤，每层携带时间戳、Token 数、模型 ID、工具参数与结果、错误状态与总成本。

3. 叠加质量打分

除追踪外还要叠加"质量打分"：将人类反馈、规则校验或 LLM 评委分数挂到对应追踪上，使可观测不仅是"快不快"，更是"对不对"。这里的关键在于耦合——若分数无法回溯到具体轨迹，监控产出的就只是无人能据以行动的数据流。

4. 主流工具与标准收敛

主流工具包括 LangSmith、Langfuse、Arize Phoenix、Datadog LLM Observability、Helicone 等；行业正加速收敛到 OpenTelemetry 的 GenAI 语义约定（GenAI Semantic Conventions），以避免厂商锁定。

二十二、Agent 开发如何进行成本控制与调用优化？

1. 提示词缓存（Prompt Caching）

将稳定的系统提示与工具定义等前缀缓存复用，缓存读取的计费通常显著低于标准输入价格（Anthropic 各模型约为标准输入价格的 10%，OpenAI 约为 50%），企业级场景下可明显降低开销。由于 Agent 在长时间运行中会反复读取系统提示、工具定义与历史上下文，缓存读取往往占据 Token 消耗的很大比例。

2. 上下文裁剪与压缩

通过滑动窗口、分段摘要、丢弃陈旧历史来削减输入 Token。研究表明轨迹裁剪可在保持任务表现的同时减少 39.9%～59.7% 的输入 Token。

3. 模型路由（Model Routing）

将分类、抽取、摘要等简单步骤交给小模型，仅将规划、复杂推理交给前沿大模型，整体 Token 成本常可下降 40%～60%。

4. 步数 / 重试上限与预算治理

设置每任务、每 Agent、每部门的多层预算与熔断，阻断无效循环与扇出激增；Gartner 2026 年 3 月分析指出，Agent 类模型的单任务 Token 消耗可达标准聊天机器人的 5～30 倍，故预算治理不可或缺。

5. 非 Token 成本的归因

非 Token 成本同样需计入：向量数据库查询、网页 / 浏览器 API、代码执行沙箱、长期状态存储与可观测管道等，均应在成本核算中按"每次完成任务"而非"每次请求"归因（业界常见的成本归因口径）。

二十三、Agent 开发如何接入企业既有的业务系统与数据？

1. 知识接入：RAG 与权限继承

将企业私域文档切片、向量化后存入向量数据库，通过 RAG 在推理时检索注入上下文，使 Agent 基于专属知识回答，缓解幻觉与知识停滞。工程上需配套权限继承——检索结果必须按用户权限过滤，而非全库召回。

2. 工具接入与云上托管平台

通过 API、MCP 服务器或函数计算连接 CRM、ERP、工单、邮件等系统，让 Agent 能读写业务数据并执行动作；优先使用开放标准以降低定制成本。在云上可选用托管平台承载这套能力，例如腾讯云智能体开发平台 ADP 以"三层引擎 + 全生命周期管理"架构提供知识引擎（RAG）、工作流引擎与 Agent 引擎，配套模型广场、插件广场与内置评测能力，支持公有云、私有云与混合云部署；腾讯云向量数据库 VectorDB 作为 Agent 记忆与 RAG 的核心组件，提供全托管服务、单索引千亿级向量规模与百万级 QPS，并集成 Embedding 与端到端 AI 套件。

3. 身份与权限

借助企业身份（如 CAM / SSO）与最小权限策略，对 Agent 的数据与操作做细粒度授权，并保留审计轨迹，满足合规要求。

4. 渠道与编排

通过连接器将 Agent 发布到企业微信、微信、小程序、网站或内部系统，并与 RPA、人工流程在编排层协同，形成"Agent + 机器人 + 人"的混合自动化。

5. 数据治理

对跨系统的数据流转做脱敏、留存与回溯设计，确保 Agent 在访问敏感业务系统时符合企业的安全与监管要求。

二十四、Agent 开发常用哪些开发框架与工具链？

1. LangGraph

以有向图状态机显式管理状态与控制流（循环、分支、并发），支持检查点持久化与人工介入，适合复杂、有状态、需高可靠性的企业级工作流。

2. CrewAI

以"角色—任务—流程"抽象模拟人类团队，层级化、中心化调度，流程可视化与异常处理成熟，适合模块化、流程明确的生产型任务。

3. AutoGen

以可对话 Agent 与群聊（GroupChat）实现动态协商，事件驱动异步架构灵活，适合研究性、创意性或需反复讨论的任务。

4. 轻量 / API 型方案

轻量 / API 型方案（如 OpenAI Agents SDK、Microsoft Agent Framework 等）更适合快速验证与简单工具调用。Anthropic 的建议是：先用 LLM API 直接实现，确有需要时再引入框架；若使用框架，需理解其底层代码，因为对框架行为的错误假设是常见故障来源。

5. 选型原则

选型原则是以业务复杂度与流程控制需求为先，避免过度工程化，并保持 API 抽象层以便迁移。评估与可观测通常独立于编排框架接入，可跨框架使用，使工具链解耦、可替换。

二十五、Agent 开发应该如何选择单智能体架构与多智能体架构？

1. 单智能体：默认起点

单智能体是默认起点。LangChain 的明确建议是：从单个 Agent 加良好的提示工程开始，一个提示得当、配少量工具的 LLM 就能解决相当大一部分真实问题；需要新能力时应先加工具，因为加工具比把推理拆分到多个 Agent 更便宜也更容易调试。

2. 升级为多智能体的明确信号

只有当出现明确的架构边界时才升级为多智能体，主要信号包括：上下文溢出（单个 Agent 难以承载所需信息量）、能力过载（工具与职责过多导致选择困难）、以及团队边界（不同团队负责不同能力域，需独立演进）。

3. 多智能体的真实代价

多智能体的代价是真实的：上下文需显式跨 Agent 传递（子 Agent 不继承主 Agent 历史）、协调开销增加、故障面扩大、调试链路变长。因此若单 Agent 尚未触及上述限制，拆分为多智能体属于过度设计。

4. 与多步骤工作流的边界区分

需要区分的是"多智能体"与"多步骤工作流"：若子 Agent 的分派规则由代码预先固定、每步路径确定，本质仍是 Workflow；若主 Agent 在运行时基于已知信息动态决定拆分与委派，才属于多智能体编排。判断依据是"谁来决定拆分"，而非"是否有子 Agent"。

二十六、Agent 开发与传统软件开发流程有什么本质差异？

1. 确定性 vs 概率性

传统软件以固定规则（if-else / DAG）保证"相同输入得到相同输出"；Agent 由 LLM 驱动，输出具有随机性与概率分布，同样的输入可能得到不同结果。

2. 调试范式不同

传统软件依赖栈追踪定位失败行；Agent 的失败常是"语义层面"的——代码执行成功但回答错误或偏离策略，需要轨迹回放与质量打分才能诊断。

3. 测试体系不同

传统以单元测试断言为主；Agent 需引入评估集、LLM 评委、轨迹评测与回归测试，将"评估即代码"作为发布门禁。

4. 交付与运维不同

传统强调 CI/CD；Agent 强调 AgentOps / Cognitive CI/CD，上线需经历影子模式、灰度、逐步提升自主度，并以持续监控与反馈回流驱动迭代。这一差异的根源在于：传统测试断言的是"代码是否按写好的逻辑执行"，而 Agent 的正确性无法脱离任务结果判定——当你我都难以判断一个正确回答应该长什么样时，Agent 同样无法稳定做到。这也是评估必须左移到开发期的根本原因。

二十七、Agent 开发与工作流自动化有什么区别？

1. 决策基础不同

工作流自动化（含 RPA）是规则驱动（Rule-based）、确定性、可预测的"指令执行者"，按预录脚本重复运行；Agent 是目标驱动（Goal-based）、动态决策、自主行动的"决策者"，只需给定目标即可自行规划。

2. 适应能力不同

RPA 在界面或数据格式变化时容易失效、需人工重编；Agent 能理解非结构化输入（邮件、PDF、图像、语音），并随环境动态调整策略，可自主处理大量边缘情形。

3. 成本与可预测性不同

工作流单次执行成本固定、易于预算；Agent 的调用次数与路径不可预知，Token 消耗可达标准聊天机器人的数倍至数十倍（Gartner 2026 年 3 月），且存在不确定性风险。

4. 适用边界不同

工作流适合高可靠、重复、格式稳定的单点任务；Agent 适合跨系统、需判断与协商的端到端复杂流程，二者常互补共存——用工作流保证稳定执行，用 Agent 处理不确定与复杂决策。

5. 行业趋势

行业趋势上，Gartner 将 Multiagent Systems（多智能体系统）列入 2026 年战略技术趋势，并预测到 2028 年至少 15% 的日常工作决策将由 Agentic AI 自主完成，标志着自动化正从"执行动作"迈向"模仿思考"。