驯服AI Agent的不确定性：从简历筛选系统得到的教训
问题
我构建了一个 resume-jd-matcher agent 来自动化候选人筛选。结果我把同一份简历在 agent 上运行两次，得到了不同的分数。第一次运行给候选人打了 78/100 分。第二次运行：68/100 分。同一份简历。同一个职位描述。不同的结果。
这不仅仅是令人恼火——而是很危险。基于不一致的评估，我如何信任招聘决策？当同一份简历可能因评估时间不同而得分不同时，我如何确保对候选人的公平性？
核心挑战： AI agents 完成任务的方式与传统程序不同。它们是概率性的，而非确定性的。由于采样和上下文变化，相同的输入可能产生不同的输出。在许多方面，AI 的行为更像人类判断而非代码执行。
类比：AI 的不确定性 ≈ 人类的主观性
这个问题让我觉得很熟悉。人类招聘经理面临同样的挑战：
- 今天和明天评审同一份简历可能会得出不同的评价
- 不同的面试官对同一候选人有不一致的看法
- 很难量化什么是"足够好"
但人力资源领域经过数十年发展了最佳实践来解决主观性问题。我们能否将同样的原则应用到 AI agents？
人类如何确保客观性
在设计公平的评估系统时，HR 专业人员使用几种策略：
1. 流程分解
将判断过程分解为多个步骤。对于确定性步骤，使用程序化检查（例如，"候选人是否有学士学位？" → 是/否）。对于主观步骤，提供明确的标准。
2. 详细的评分标准
不使用模糊的评估（"强候选人"），而是使用量化评分和明确的公式：
- 3年经验 = 8分
- 4年经验 = 9分
- 5年以上经验 = 10分
3. 审查和一致性检查
比较评估以识别不一致性。标记异常值进行重新审查。
4. 多评审员验证
多人评估同一候选人。综合他们的独立判断。
5. 参考基准
提供校准示例："这是 90/100 候选人的样子。这是 70/100。"
6. 反馈循环
追踪误判（高估、低估）。根据实际结果更新标准。
将这些原则应用到 AI Agents
以下是我如何将 HR 最佳实践转化为我的 AI agent 系统：
1. 流程分解 → 工作流 + Skills/MCP
- Agents 天然支持工作流： 将评估分解为阶段（信息提取 → 证据分类 → 分数计算）
- 确定性部分 → 工具： 对于程序化检查（例如，计算工作年限），使用 Skills 或 MCP 工具而非 LLM 推理
2. 详细评分标准 → Prompt 中的明确公式
创建了 scoring-rubric.md，为每个类别提供精确公式：
## 工作年限 (10分)
if 相关经验年限 >= 5年:
得分 = 10分
elif 相关经验年限 >= 3年:
得分 = 8分 + (年限-3) × 1分
elif 相关经验年限 >= 2年:
得分 = 6分
这消除了歧义。agent 现在有明确的数学指导，而不是"评估经验水平"。
3. 审查和一致性 → 校准检查
在 agent prompt 中添加了校准步骤：
**校准检查**
- 最相似于：[参考示例 A/B/C/D]
- 分数差异：[比参考高/低 X 分]
- 理由：[如果差异 >10 分，解释原因]
Agent 必须将每次评估与基准案例进行比较，并为偏差提供理由。
4. 多评审员 → 多 Agent 验证
通过多个 agent 配置运行同一份简历：
- Agent A（保守派）：严格标准
- Agent B（平衡派）：标准标准
- Agent C（乐观派）：更看重潜力
如果分数偏差 >10 分，标记为需要人工审查。
5. 参考基准 → 示例简历库
创建了 reference-resumes.md，包含 4 个校准示例：
- 示例 A： 92/100（强烈推荐）- 深度内核专家，6年经验
- 示例 B： 76/100（有保留地推荐）- K8s 强但内核深度弱
- 示例 C： 58/100（也许）- 应用开发转基础设施
- 示例 D： 32/100（不推荐）- IT 支持无编程经验
这些锚点帮助 agent 理解不同分数区间代表什么。
6. 反馈循环 → 误判追踪
面试后记录：
- 候选人：John Doe
- 简历分数：82/100
- 面试结果：拒绝（系统设计失败）
- 根本原因：Agent 给 Kubernetes 打了 17/20 分，但候选人只会 kubectl 基础操作
- 行动：更新标准 - "会用 kubectl" 应该打 3-4/10 分，而非 8/10 分
前后对比
原始 Agent
- Prompt： 通用指令（"评估候选人对该职位的适配性"）
- 评分： 主观匹配级别（强/部分/弱）
- 输出： 叙述性评估
- 一致性： 同一简历 ±10 分方差
改进后的 Agent
- Prompt： 明确的工作流，强制读取评分标准
- 评分： 7 个类别的量化公式（教育、经验、内核/Linux、编程、Kubernetes、相关经验、领导力）
- 输出： 带证据引用的表格化分解
- 一致性： ±4 分方差（50% 改进）
量化影响
| 指标 | 之前 | 之后 | 改进 |
|---|---|---|---|
| 分数方差 | ±10 分 | ±4 分 | 减少 60% |
| 可解释性 | 叙述性 | 表格 + 证据 | 质的提升 |
| 校准 | 无 | 4 个参考案例 | N/A |
| 保守评分 | 否 | 是（不确定时向下取整） | 减少误报 |
生产安全问题
这引发了一个现实业务团队应用Agent至关重要的问题：如果 AI agent 的行为不可预测，在生产环境中使用它们是否很危险，错误可能造成不可逆转的破坏？
对生产环境的错误更改可能级联导致中断、数据丢失或安全漏洞。
让 AI Agents 在生产环境中安全运行
我们可以应用相同的最佳实践，外加额外的保障措施：
1. 相同的核心原则
- a) 流程分解： 将确定性工作（通过 Skills/MCP 使用程序化检查）与 AI 决策分离
- b) 验证和回滚步骤： 每个更改都必须有验证阶段和回滚计划
- c) 错误追踪： 在 agent prompts 中记录过去的错误以防止重复
2. 额外的生产保障措施
a) AI 做计划，人类执行
- AI agent 生成实施计划
- AI 在测试/暂存环境中测试计划
- 人类审查计划并在生产中执行
示例：
Agent: "这是升级系统的迁移计划..."
[Agent 在测试集群中运行计划]
Agent: "测试通过。这是生产 runbook。"
Human: [审查、批准、执行生产更改]
b) 确定性代码生成
对于有明确规范的程序化任务，使用 AI 进行 "vibe coding"：
- AI 编写代码
- 测试验证正确性
- 代码审查确保质量
- 在生产中确定性执行
c) 利用 AI 的文档优势
AI 擅长文档编写。用它来：
- 为每个操作生成详细的 runbook
- 自动维护变更日志
- 从事故数据创建事后分析
这保留了机构知识并实现可审计性。
d) 保持人类参与
AI 是副驾驶，而非自动驾驶：
- 人类驱动： 人启动并引导工作流
- 关键步骤批准： 危险操作需要人类确认
- 人类审查： 人审查文档，提供反馈
- 持续改进： 来自人类监督的反馈循环改进 agent 行为
关键安全属性：
- 确定性检查（兼容性、健康）使用程序化工具
- AI 处理规划和文档（非破坏性）
- 人类批准每个阶段转换
- 健康检查失败时自动回滚
AI Agent 开发最佳实践
基于这次经验，我提出以下构建可靠 AI agents 的指南：
对于非破坏性任务（例如，简历筛选）
-
量化一切
- 用数值分数替代主观评估
- 提供明确的公式和阈值
- 为每个声明引用证据
-
提供参考锚点
- 在 prompts 中包含校准示例
- 定义"优秀"与"差"的样子
- 强制 agents 将输出与基准比较
-
强制一致性检查
- 在工作流中构建校准步骤
- 标记大偏差以供审查
- 随时间追踪方差
-
默认保守
- 不确定时，向下取整分数
- 宁可误报（false negative）而非漏报（false positive）
- 明确承认不确定性
对于破坏性/影响现实生产环境的任务
-
分离规划与执行
- AI 生成计划并测试
- 人类批准并执行关键更改
- 明确的关注点分离
-
自动化验证
- 每个更改都有程序化健康检查
- 失败时自动回滚
- 没有 AI 决策是最终的，没有验证
-
记录一切
- AI 为每个操作生成 runbook
- 变更日志自动且详细
- 事后分析包括 AI 决策理由
-
人类监督是强制性的
- 危险操作需要明确批准
- 人类审查所有 AI 生成的文档
- 反馈循环：人类纠正 AI 错误
-
故障安全
- AI 不确定时默认无操作
- 不可逆操作需要明确确认
- 优雅降级：回退到手动流程
号召行动
这些是基于一个用例（简历筛选）和生产系统，开发和应用Agent的初步最佳实践。我分享它们是为了开始对话。
我邀请你贡献你的经验：
- 你是否构建了有一致性挑战的 AI agents？
- 你使用了什么技术来确保可靠性？
- 对于生产环境，我们应该考虑哪些额外的保障措施？
讨论
你在 AI Agent 一致性方面遇到了什么挑战？在评论中分享你的经验和建议。
