跳至主要內容

AI Agent 原理与工程实践

约 1916 字

AI Agent 原理与工程实践

什么是 AI Agent

AI Agent（人工智能智能体）是一个以模型为决策核心、能够根据目标选择行动并通过外部工具影响环境的应用系统。与只根据输入生成一次回答的聊天模型不同，Agent 通常会在“观察—决策—行动—观察结果”的循环中运行，直到完成任务、达到停止条件或需要人工介入。

Agent 并不意味着模型本身拥有自主意识。它的行为由模型、系统指令、工具接口、上下文状态和应用程序控制逻辑共同决定。

Agent 与固定工作流

固定工作流由程序预先规定步骤，路径通常清晰、可预测，适合规则稳定、结果容易验证的任务。Agent 则可以依据中间结果动态选择下一步行动，适合需要探索或处理不确定输入的任务，但也更难预测和测试。

实际系统经常采用混合方式：由程序控制关键流程和权限，在有限的步骤中让模型判断、选择工具或整理结果。并非所有使用大语言模型的应用都需要 Agent；如果一次模型调用就能可靠完成任务，采用固定流程通常更简单。

核心组成

一个常见的 Agent 系统包含以下部分：

  • 模型：理解当前上下文，生成回答或行动建议。
  • 指令与策略：规定目标、边界、可用工具和停止条件。
  • 工具：把模型的行动请求映射为受控的外部操作，例如查询只读数据或调用业务 API。
  • 编排器：负责校验模型输出、调用工具、处理结果、维护状态和限制循环次数。
  • 状态与上下文：保存当前任务、对话历史、已完成步骤及工具返回值。
  • 用户界面与人工审批：展示进度和依据，并在高影响操作前请求确认。

模型通常只负责提出结构化的工具调用请求；实际执行应由应用程序完成，而不是直接执行模型生成的任意文本。

工具调用循环

下面是一个简化的执行过程：

  1. 接收用户目标，并检查输入与权限。
  2. 将任务、必要上下文和工具定义发送给模型。
  3. 判断模型返回的是最终答案，还是一个符合工具 schema 的调用请求。
  4. 校验工具名称、参数类型、范围与调用权限。
  5. 执行获准的工具，将结果作为新的上下文交还模型。
  6. 重复决策与工具调用，直至模型返回答案或触发停止条件。
  7. 将结果和必要的来源信息返回给用户。
state = initialize(task)

for step in range(max_steps):
    response = model.generate(context=state.context, tools=allowed_tools)

    if response.is_final:
        return validate_and_present(response)

    call = validate_tool_request(response.tool_call, allowed_tools)
    result = execute_tool(call)
    state = append_observation(state, call, result)

return report_incomplete_task(state)

此伪代码省略了超时、重试、取消、异常分类和审计等生产环境必需的处理。达到步数上限时应明确报告任务未完成，不能把中断伪装成成功。

工具接口设计

工具接口是模型与业务系统之间的边界。好的接口应保持职责单一、名称和参数清晰，并对输入进行程序级校验。例如，“查询订单状态”比“处理订单”更容易限定权限与副作用。

设计工具时应考虑：

  • 参数 schema：定义必填字段、数据类型、枚举值和长度范围；应用层仍需再次校验。
  • 权限最小化：只开放完成任务所需的操作，区分读取与修改权限。
  • 副作用控制：删除、发送、付款等不可逆或高影响操作，应要求确认或使用专门的审批流程。
  • 幂等与重试：对可能重复执行的写操作使用幂等键，并明确超时后的状态查询方式。
  • 错误表达：返回可区分的错误类型和可操作信息，避免将失败包装成正常结果。
  • 审计记录：记录调用主体、参数摘要、执行结果和审批信息，并按数据策略处理敏感内容。

上下文、状态与记忆

Agent 的上下文是当前一次模型调用可见的信息；任务状态是系统在多步执行中保存的结构化进度；长期记忆则是在任务之间保留并按需检索的信息。三者不应混为一谈。

上下文窗口有限，因此应用需要控制历史长度、压缩已完成步骤，或检索当前任务真正需要的资料。状态中应清楚区分用户输入、工具观察和模型推断，避免把未经验证的推断记录为事实。写入长期记忆前也应判断必要性、访问权限、保留期限和用户预期。

可靠性与安全边界

Agent 的风险不仅来自模型回答错误，还来自错误行动被工具执行。工程上应把模型视为不可信的决策输入，并在应用层实施边界：

  • 在模型和工具之间设置明确的权限检查，不能仅依靠提示词限制操作。
  • 对每次工具调用检查参数，并限制调用次数、执行时间和资源消耗。
  • 对工具返回内容进行标注和隔离；外部文档或网页中的指令不应覆盖系统策略。
  • 对高风险动作实施人工确认、双重校验或回滚机制。
  • 保护凭据与个人信息，避免不必要地写入提示词、日志或记忆。
  • 支持取消任务，并在失败或超限时返回清楚的部分结果与失败原因。

评估与可观测性

只测最终答案是否“看起来正确”，不足以评估 Agent。还应分别检查任务完成率、工具选择与参数正确率、步骤数、延迟、成本、权限拒绝情况，以及失败后是否安全停止。

可以为典型任务建立测试集，记录预期结果、允许的工具和禁止的副作用。运行时保留必要的结构化追踪，例如每一步的决策类型、工具名称、耗时和错误类别；对提示词、输出和工具参数中的敏感数据应脱敏或限制记录。上线后应监控异常循环、工具失败率和人工接管率，并对模型或指令变更进行回归测试。

设计检查清单

  • 是否确实需要动态决策，而不是更简单的固定工作流？
  • 每个工具是否职责单一、参数受校验、权限最小化？
  • 是否限制了最大步数、超时、重试和资源消耗？
  • 写操作和高影响操作是否有审批或补偿方案？
  • 工具失败、无答案和超限时是否能明确告知用户？
  • 是否能通过追踪与测试复现并评估 Agent 的行为？

小结

AI Agent 是由模型、工具和应用编排共同组成的系统。其关键工程问题不是让模型“更自主”，而是让每一步行动都可校验、受授权、可观察，并能在失败时安全停止。对于不需要动态选择行动的任务，优先使用更简单且可预测的实现。

上次编辑于: