AI agent 上线后，用户和业务人员会不断给反馈：这个答案不够具体、这个工具不该调用、这个步骤应该先问人、这个格式系统读不了。如果这些反馈只停留在聊天记录里，agent 不会真正变好。
人工反馈闭环的目标，是把“哪里不好”转成可分析、可排序、可回归的样本。反馈如果不能进入评测集、工具改造或 prompt 版本管理，就只是情绪记录。
先给结论：反馈要结构化，而不是只收一句评价
| 字段 | 作用 |
|---|---|
| taskId | 找回完整执行过程 |
| issueType | 区分问题类型 |
| expectedBehavior | 期望 agent 怎么做 |
| severity | 判断优先级 |
| correctedOutput | 可作为回归样本 |
| reviewer | 记录反馈来源 |
没有结构化字段，反馈很难进入工程改进。
一个可落地的反馈数据结构
反馈表不要太复杂，但一定要能找回上下文和期望行为：
{
"feedbackId": "fb_20260506_001",
"taskId": "agent_run_123",
"stepId": "tool_call_02",
"issueType": "tool_selection_error",
"severity": "high",
"userComment": "这里不应该直接发通知，应该先给我确认。",
"expectedBehavior": "生成预览并进入 human_review",
"correctedOutput": {
"nextAction": "human_review",
"reason": "外发动作需要确认"
},
"reviewer": "content_ops",
"createdAt": "2026-05-06T11:00:00Z"
}
其中 taskId 和 stepId 很重要。没有它们，就无法回放当时模型看到了什么、工具返回了什么。
一、反馈入口要贴近使用场景
不要只放一个“是否满意”。用户需要快速标出问题：答案不准确、缺字段、工具调用错、越权、格式错误、需要人工接管。
反馈入口越具体，后续越容易聚类。
建议把反馈入口拆成两层：
| 入口 | 面向谁 | 用途 |
|---|---|---|
| 快速反馈 | 普通用户 | 标记有用、无用、需要人工 |
| 结构化标注 | 运营或审核人员 | 记录问题类型、期望行为、严重程度 |
普通用户不应该被要求填写一堆字段；但内部审核人员必须能把问题标清楚。
二、标注要区分问题类型
建议至少分为：
- 意图理解错误
- 资料依据不足
- 输出格式错误
- 工具选择错误
- 参数缺失
- 权限边界问题
- 需要人工确认但未暂停
- 语言表达不清楚
不同类型对应不同修复方式。不要把所有问题都归因于“模型不行”。
问题类型和修复层级可以直接对应：
| issueType | 优先排查层级 |
|---|---|
| intent_misread | prompt contract / 输入字段 |
| missing_context | RAG / 上下文注入 |
| wrong_tool | 工具描述 / 工具路由 |
| bad_parameters | schema / 参数校验 |
| unsafe_action | 权限 / 人工确认 |
| output_format | 输出 schema / parser |
| weak_answer | 知识库 / 生成策略 |
这样复盘时不会一上来就改 prompt。很多问题其实应该改工具、数据或权限。
三、修正样本要进入回归集
高价值反馈不只是记录，还要变成下一轮测试样本。尤其是高频问题、高风险问题、已经影响业务的问题。
流程可以是：
用户反馈 -> 人工标注 -> 修正期望输出 -> 加入回归集 -> 修改 prompt / 工具 / 数据 -> 重新评测
这样 agent 改进才有闭环。
进入回归集前，样本要做三件事：
| 处理 | 原因 |
|---|---|
| 脱敏 | 避免真实用户信息进入测试集 |
| 最小化 | 只保留复现问题所需字段 |
| 写期望 | 明确下一次应该通过什么标准 |
一个反馈样本不要直接复制完整对话。它应该变成一个能稳定复现问题的测试用例。
四、不要把所有反馈都立刻改 prompt
有些问题来自知识库，有些来自工具 schema，有些来自权限配置，有些才是 prompt。直接改 prompt 可能解决一个样本，又破坏其他任务。
反馈分析要先定位问题层级，再决定改哪里。
可以用一个简单优先级公式排序：
priority = severityWeight * frequency * businessImpact * confidence
其中 confidence 表示你对根因判断的把握。如果反馈很多但根因不清，先抽样复盘，不要急着改线上 prompt。
五、建立每周反馈复盘节奏
反馈闭环需要固定节奏，否则样本会堆积。一个轻量流程是：
- 每天自动聚类新增反馈。
- 每周挑选高频和高风险样本。
- 标注根因层级：prompt、工具、知识库、权限、产品流程。
- 为每个修复创建回归样本。
- 发布后观察同类问题是否下降。
衡量反馈闭环是否有效，不看收集了多少反馈，而看同类问题是否减少。
六、失败案例：用户反馈很多，但没有改进路径
一个 agent 上线后收集了大量“有用/没用”评价。团队知道体验一般，却不知道具体问题在哪里。后来改成结构化反馈：问题类型、期望行为、是否影响业务。两周后就发现 60% 问题来自输出格式不稳定，而不是知识缺失。
修复输出 schema 后，整体满意度明显提升。更关键的是，团队把“输出格式不稳定”做成 12 条回归样本，之后每次改 prompt 都先跑这组样本。
七、反馈闭环 Checklist
- 反馈是否关联 taskId
- 是否区分问题类型
- 是否记录期望行为
- 高风险反馈是否优先处理
- 修正样本是否进入回归集
- 是否先定位问题层级再修改
- 是否定期复盘反馈分布
- 反馈是否能定位到具体 run 和 step
- 样本进入回归集前是否脱敏和最小化
- 修复后是否观察同类反馈下降
结语
人工反馈不是客服意见箱，而是 AI agent 的持续改进数据源。把反馈结构化、样本化、回归化，再按根因层级修复，团队才能知道 agent 应该改 prompt、改工具、改知识库，还是改权限边界。
延伸阅读：
