L2 · 企业 FDE 实践者主修课40 分钟

Agent 生产架构、评估与可观察性

将 Agent 控制、业务评估和运行遥测组成可定位故障的生产架构。

Agent 生产架构业务评估可观察性故障定位
本课目录
所属等级L2 · 企业 FDE 实践者
课程类型主修课
预计时长40 分钟
先修建议完成 L2-E01 真实企业集成;有可运行的 Agent 或工作流与代表性任务样例

Agent 方案设计连接业务与工程。它需要同时说明用户、价值、流程、上下文、工具、控制、评估和运营,让业务看得懂,也让技术团队知道怎样实现。AI 系统的错误无法完全消除,但可以被设计、测量和控制。评估不仅看平均准确率,还要看错误发生在哪里、影响多大、是否能发现,以及人工兜底是否真实有效。本课要求工程主修用端到端证据说明系统在正常、异常和高风险任务中如何表现,以及如何通过日志、指标和追踪定位故障。

  • 定义 Agent 输入输出、工具、状态与失败控制
  • 建立 Golden Set 与业务风险评估
  • 实现可定位、可告警的端到端可观察性

从概念到可执行判断

01

Agent PRD 与生产控制

规则明确、步骤稳定的任务优先使用固定 Workflow;需要在多种工具与路径中动态选择时,才考虑 Agent。很多可靠系统其实是“固定骨架+局部 Agent 判断”。

不要把多 Agent 当作先进程度。每增加一个 Agent,就增加一次理解偏差、通信、成本与治理难度。

输入契约说明来源、格式、必填项、权限与完整性;输出契约说明结构、使用者、后续动作和质量要求。

缺少关键输入时,系统应主动询问、拒绝或转人工,而不是猜测补齐。结构化输出可以减少后续系统解析错误。

一份 Agent PRD 包含用户与场景、业务价值、流程、人机分工、输入输出、上下文、工具、状态、评估、风险、日志、成本和维护责任。

PRD 的目的不是写得厚,而是让业务、技术与治理角色对同一系统形成可执行共识。

02

工具、状态、记忆与失败控制

Skill 是可复用的业务动作,例如检索制度、计算指标、查询库存、生成草稿或创建工单。每个工具都要定义参数、权限、返回结果和失败方式。

查询、建议、写入和外部发送具有不同风险。高风险工具需要更严格的身份、审批、范围和审计。

工作流需要知道任务进行到哪里、哪些信息已经确认、哪个版本正在运行。记忆应服务当前任务,不应无边界保存所有对话和敏感资料。

重试要有上限,超时要能降级,不确定要能转人工,不可逆动作要有确认。失败控制是 Agent 设计的一部分。

03

Golden Set 与多维评估

同一个“准确率”在不同场景意义不同。营销草稿可以允许人编辑,合规审核漏掉关键风险则可能造成重大损失。评估标准必须与任务、责任和风险容忍度对应。

模型不能只给自己打分。业务专家需要参与定义样本、标准答案、可接受差异与严重错误。

Golden Set 是持续使用的代表性评估集,应覆盖常见任务、边界情况、异常输入和对抗情况。每条样本记录来源、预期结果、判断依据和严重程度。

评估集不是一次性考试卷。生产中发现的新失败模式,应经过审核后回流,形成持续改进资产。

质量可以看准确性、完整性、一致性、来源可追溯和格式合规;工程可以看时延、成本、稳定性;业务可以看效率、质量、增长或风险;采用可以看实际使用与绕行。

指标不宜过多。选择能够支持当前 Scale、Iterate 或 Stop 决策的最小指标集。

04

错误分类与安全上线门

错误可能来自输入缺失、知识过期、检索失败、模型推理、工具调用、流程设计或人工使用。只有分类,才能把问题交给正确负责人。

根据发生频率、业务影响和可发现性排序。低频但不可发现的严重错误,可能比高频格式问题更值得优先处理。

风险台账记录场景、触发条件、影响、控制措施、Owner 与监测方式。需要考虑隐私泄露、权限越界、提示注入、错误执行、内容风险和供应商变化。

上线门明确最低质量、人工兜底、日志、回滚和停止条件。治理从场景定义开始,不是在上线前补一张表。

05

建立日志、指标、追踪与告警

为请求、模型、检索、工具、权限、人工接管和业务结果建立可关联追踪,对错误率、延迟、成本和高风险失败设置有业务意义的告警。

同样的错误率,不同的业务后果

业务现场

内容运营、采购数据处理和医药合规都可能使用文本模型,但错误后果差异巨大。

采取动作

内容场景允许编辑与抽检;采购场景加强结构校验;合规场景要求来源引用、人工批准和审计记录。

关键启示

安全要求不是由模型名称决定,而是由具体任务、责任、可逆性和业务影响决定。

Agent PRD 八格

方案评审前,检查八个格子:

01用户

谁在什么场景使用?

02价值

改变哪项业务结果?

03流程

步骤、人机分工和异常是什么?

04上下文

依据哪些规则、知识和实时状态?

05工具

需要查询或执行什么,权限如何?

06控制

状态、确认、转人工和失败退出怎样设计?

07评估

用哪些样本和指标验收?

08运营

日志、成本、版本和维护由谁负责?

先回答,再展开答案

01什么情况下固定 Workflow 通常优于 Agent?

步骤与规则稳定、可预测,并且需要较强可控性时。

02为什么工具写入权限比查询权限风险更高?

写入会改变真实业务状态,可能造成不可逆影响,需要确认和审计。

03为什么不能只看平均准确率?

平均值会掩盖严重错误、边界失败、业务影响和可发现性。

04错误分类有什么价值?

帮助定位输入、知识、检索、模型、工具、流程或使用问题,并分配正确负责人。

把方法带回真实工作

PRIMARY

企业内部推进(默认)

为内部真实试点完成 Agent 端到端评估和可观察性走查。

OPTIONAL

外部客户交付(可选)

与客户工程和运行角色共同验证生产评估与告警。

所需材料

  • 目标流程
  • 上下文地图
  • 系统接口
  • 评估与安全要求
  • 代表性样本
  • 业务标准与专家
  • 运行日志
  • 数据安全与合规要求
  • Agent PRD
  • 代表性脱敏样本
  • 测试环境与权限
  • 目标用户与运行负责人

交付物

  • Agent PRD 与工具权限图
  • Golden Set 与端到端评估报告
  • 日志、告警、追踪与可观察性看板

通过标准

  • 评估覆盖正常、异常和高风险任务
  • 可从业务失败追溯到模型、检索、工具、权限或人工节点
  • 重要故障有可执行告警和升级路径

能力证据

  • 一次端到端运行、多维评估与故障定位证据
  • 一项真实或注入异常触发的日志、追踪、告警与人工接管记录

填写模板或完成课程不等于能力达标;通过必须以真实任务、现场行为和可复核证据为依据。