Brian Chiu
Back to Home
Develop

AI Agent理解与工程实践建议

Understanding and practical advice on AI Agent design.

9 min read
AI Agent理解与工程实践建议

引言

LLM 的进步带来了新一代自动化系统 AI Agent，学术界对于Agent的概念和内涵仍在定义和讨论中，而工程领域已经涌现了一些最佳实践，可以指导我们搭建企业级别落地AI Agent。本文从 Agent 定义出发，结合OpenAI的专业指导，根据作者Agent设计实践提出了几点工程建议。

传统vs Agent

什么是 Agent？

目前对于Agent没有统一定义，不同公司根据自身业务有不同的定义，以OpenAI和Anthropic对于agent的定义最为典型：

OpenAI：Agent 是一种能够代表你独立完成任务的系统。

Anthropic：智能体系统是LLM动态指导自己的流程和工具使用，保持对完成任务方式的控制的系统。

维度 OpenAI Anthropic
关键词 代表、独立、完成任务 动态、工具使用、控制
Agent 与 Workflow 的关系 Agent = 新的 workflow schema，本身是“流程系统”的升级版 Agent 和 workflow 是两个并列的概念
Agent 定位 端到端执行者，替代传统工作流引擎 动态决定自身过程和工具使用，控制自身完成任务的方式
重点 如何让 Agent 可靠执行完整流程（模型 → 工具 → 指令 → 护栏） 如何在 workflow 中嵌入安全的 Agent（对齐 → 宪法 → 人机协作）
思路风格 工程/产品导向 安全/价值导向

核心特征

  1. 自主执行工作流
    1. 借助 LLM 识别任务状态
    2. 可判断流程是否完成
    3. 必要时主动修正或终止
  2. 工具调用能力
    1. 可访问外部系统（数据库、CRM、邮件系统等）
    2. 根据上下文动态选择合适工具
    3. 始终在安全边界（Guardrails）内运行

与 RPA 的区别

特点 RPA Agent
执行方式 固定脚本 动态推理
适用场景 规则清晰、流程固定 非结构化数据、复杂决策
错误处理 报错或终止 自我修正或交回用户
工具能力 仅限预定义接口 可动态扩展工具集

Agent机制

什么时候需要构建 Agent？

Agent 的优势在于它能处理 传统方法难以应对的复杂性 。以下场景特别适合：

  1. 复杂决策例：退款审批、保险理赔，需要结合上下文和例外情况判断。
  2. 难以维护的规则例：供应商安全审核，规则繁多且更新频繁，传统规则引擎成本高。
  3. 高度依赖非结构化数据例：处理客户邮件、解析 PDF 文档、对话式交互。

👉 举个例子：

  • 规则引擎做支付风控 ：像检查清单，只能识别固定风险模式。
  • Agent 做支付风控 ：像资深调查员，能结合上下文识别新型欺诈手法。

规则引擎vs Agent

Agent 设计三大基石

要构建一个可靠的 Agent，需要三个核心要素： 模型（Model）、工具（Tools）、 指令 （Instructions） 。

模型（Model）

  • 性能基线 ：先用最强模型建立准确率基准（baseline）
  • 逐步优化 ：在保证效果的前提下，替换为更快更便宜的小模型
  • 平衡点 ：准确率、成本、延迟之间的取舍

工具（Tools）

工具类型 作用 示例
数据型工具 获取上下文信息 查询数据库、解析 PDF、搜索网页
动作型工具 执行具体操作 发邮件、更新 CRM、转人工客服
编排型工具 调用其他 Agent 退款 Agent、写作 Agent、研究 Agent

指令（Instructions）

  • 使用现有文档 ：如 SOP、知识库
  • 任务分解 ：将复杂任务拆分为更小的步骤
  • 动作明确 ：每一步都要有清晰的输入输出
  • 覆盖边界情况 ：考虑用户输入不完整或异常的情况

三大基石

编排（Orchestration）模式

当 Agent 的能力不断扩展，如何协调它们的运行成为关键问题。常见有两种模式：

单 Agent 系统

  • 一个 Agent 循环执行任务
  • 通过 Prompt 模板适配不同场景
  • 简单易维护，适合早期原型

多 Agent 系统

当单 Agent 难以应对复杂场景，可以拆分为多个 Agent 协作。

典型模式：

  1. Master-Slave （ 主从模式 ）

    • 一个核心 Agent 负责协调
    • 子 Agent 各司其职
    • 用户交互只通过 Master 智能体完成

  2. Decentralized（去中心化模式）

    • 多个 Agent 平级
    • 可相互“交接任务”
    • 适合客服分流、订单处理等场景

编排模式

Guardrails（护栏设计）

Agent 强大但也有风险，因此需要 护栏（Guardrails） 来保证安全、合规和用户体验。

为什么需要护栏？

  • 隐私风险 ：防止泄露系统提示或用户敏感数据
  • 品牌风险 ：避免生成不符合企业价值观的内容
  • 安全风险 ：防止危险操作（如未经授权的退款）
  • 行为兜底 ：提升系统操作成功率

常见安全护栏类型

类型 功能 示例
Relevance classifier 保证内容相关性 拦截跑题问题
Safety classifier 检测越狱/注入攻击 拒绝“输出系统提示”请求
PII 过滤 去除敏感信息 银行卡号、身份证号
Moderation 过滤不良内容 暴力、仇恨言论
工具风险分级 评估工具危险性 大额转账需人工确认
规则过滤 简单规则保护 黑名单、SQL 注入拦截
输出验证 品牌一致性 检查回复是否符合企业语气

实践建议

  1. 从数据隐私和内容安全出发
  2. 根据实际故障迭代增加护栏
  3. 在安全与体验之间找到平衡
  4. 保持人类介入能力

多层护栏

总结

Agent 标志着工作流 自动化进入新时代 。与传统自动化不同，它能在不确定环境下推理决策，跨系统执行任务，并在必要时交回用户。

构建 Agent 的关键：

  • 三大基石 ：模型、工具、指令
  • 合理编排 ：从单 Agent 起步，再扩展到多 Agent
  • 护栏保障 ：确保隐私、安全和稳定性

👉 实践建议：

  • 从小规模场景试点
  • 逐步扩展能力
  • 保持人类在环（Human-in-the-loop）机制

最终，Agent 不仅能替你完成任务，还能接管完整的工作流，帮助企业实现更高效、更智能的自动化。

Photo by @sinan