为AI智能体引入评分系统
问题在我开始在一个真实代码库上使用AI智能体时就变得显而易见了。智能体会修复README中的一个拼写错误，然后二十分钟后，以完全相同的自信水平提出对JWT（JSON Web Token）认证边界的修改。没有信号表明一个需要仔细推理而另一个不需要。没有语气变化，没有标记，没有犹豫。
我尝试了两种标准方法。自己批准每个操作把智能体变成了缓慢的橡皮图章——反正都是我在做思考。让它无人监督地运行意味着我离一个糟糕的日子只有一次遗漏的diff之遥。两种方法都不行。
所以我建立了第三个选项：一个评分过程，在智能体写一行代码之前告诉它一个任务有多大的风险。我称之为必需推理指数（RRI）。
RRI是一个确定性评分过程，将特定任务映射到操作门槛。与其信任智能体来判断一个任务需要多少推理，它给工作流一个数字：基于即将接触的代码的技术现实，这个特定的变更需要多少谨慎、验证和监督。
这个区别很重要。RRI在执行上是确定性的，在测量上并不是神奇地客观的。脚本保证相同的输入产生相同的输出，而评分标准底线降低了智能体低估敏感工作的能力。目标不是消除判断。目标是让智能体不再是自身风险的唯一裁判。
这个分数不仅设定了安全门槛。它还决定哪个模型运行任务，以及人类是否需要看到它。低RRI任务——修复文案、更新配置值、重构一个小型工具函数——可以委托给更轻、更便宜的模型并以很少的摩擦执行。高RRI任务获得更强的模型、更严格的验证，以及在实施前需要人类参与。
第三个用途我花了更长时间才看到：高分是重新规划的信号，不仅仅是升级。如果一个任务评分超过70，正确的做法通常不是给它一个更好的模型。正确的做法是将它拆分，直到每个部分的评分低于55。更小的任务意味着更少的攻击面，更少的副作用遗漏，以及更少的空间让可疑的智能体决策变成沉默的技术债务。
复杂性是债务隐藏的地方。
1、RRI在工作流中的位置
RRI不是一个独立工具。它是结构化开发循环中的决策点。
工作流看起来像这样：
- 分析——智能体读取代码库并识别受影响的文件、依赖关系和可能的影响范围。
- 规划——智能体写一个计划：目标、受影响文件、设计决策、假设和验证策略。
- 评分——智能体对任务运行
rri.py。这就是数字产生的地方。 - 展示并等待——智能体展示完整的RRI细分、区间和门槛。如果评分超过25，它停止并等待明确的人类批准才能写代码。
- 实施——一旦批准，智能体按定义的顺序逐个任务工作。
- 标记进度——每个任务后，智能体更新任务账本：做了什么、通过了什么、失败了什么、还剩什么。
ANALYZE -> PLAN -> SCORE (rri.py)
|
.------------+------------.
| | |
RRI 0-25 RRI 26-70 RRI > 70
| | |
auto-exec present & replan:
no review wait for split until
approval RRI <= 55
| | |
'------------+------------'
|
IMPLEMENT
(one task at a time)
|
MARK PROGRESS
(task ledger)
第3步的RRI分数支配着后续一切。RRI 0–25时，智能体可以自动执行：它展示即将做什么并立即开始。RRI 26及以上时，它展示计划并等待。RRI超过70时，该任务还不被视为一个实施任务。它变成一个必须先被分解的规划任务。
这是真正可扩展的人机协作模型。人类不需要批准每个操作。他们是高复杂性工作的最终权威，分数明确表明哪些工作值得那种关注。低风险任务无摩擦地流转。高风险任务在造成损害之前浮出水面。
智能体仍然参与评估，特别是在判断不可避免的地方。但它没有单方面降低敏感工作的权威。评分策略做那份工作。
2、RRI的机制
关键是从"信任模型"转向"衡量并界定风险"。一个加权公式产生0到100之间的基础分数，一组惩罚条件在特定风险条件叠加时将其推得更高。
几个例子让这个想法在公式之前更容易理解：
README拼写错误 -> 大约RRI 5-10
UI标签或文案变更 -> 大约RRI 10-20
带测试的小工具重构 -> 大约RRI 20-35
认证中间件变更 -> 大约RRI 45-65
涉及权限的迁移 -> 大约RRI 70+
架构级重设计 -> 大约RRI 100+
公式是：
RRI = 100 × ((0.18·C + 0.12·F + 0.15·D + 0.15·T + 0.12·A + 0.12·K + 0.10·P + 0.06·X) / 5) + Penalties
权重是启发式策略默认值。它们不是普遍真理，也不应被视为经过研究验证的模型。它们被故意显式化，以便团队可以争论、版本化、校准和随着真实项目数据积累而调整。
比精确权重更重要的是工具可以测量的和仍然需要判断的之间的分离。
变量 | 名称 | 性质 | 测量策略
----|-----------------------|---------------|-----------------------------------
C | 圈复杂度 | 客观 | radon、gocyclo、clippy等工具
F | 受影响文件数 | 客观 | git diff / 文件路径分析
D | 领域复杂性 | 评分标准锚定 | 涉及的层：认证、迁移、UI等
T | 测试覆盖风险 | 半客观 | 现有测试、覆盖率、特征化差距
A | 任务模糊度 | 主观 | 验收标准的清晰度
K | 耦合/副作用 | 评分标准锚定 | 下游依赖和集成点
P | 公共API/安全 | 评分标准锚定 | 故障的影响范围
X | 上下文大小 | 主观 | 智能体必须持有的代码库上下文
变量分为四个信任级别：
- 客观——由工具测量，而非估算。智能体在这里没有有意义的输入。
- 半客观——从代码库推导，但仍然需要解释。
- 评分标准锚定——原则上是主观的，但受策略映射约束。智能体可以将分数评得更高，永远不会更低。
- 主观——智能体判断。模糊性和上下文大小无法完全自动化，因此智能体必须说明其假设。
这种划分是我最关心的部分。C和F是从文件系统读取的事实。D、K和P是判断调用，所以我将它们锚定到评分标准而不是信任智能体的直觉。
任何被标记为安全边界的文件路径——认证、加密、权限、迁移——都带有强制性的最低分数。智能体可以将其评得更高，永远不会更低。这个底线阻止了智能体将安全关键变更视为简单的。
仅靠基础分数不能捕获一切。某些组合无论各个变量如何评分都需要更多的谨慎：一个同时改变行为和重构的变更，一个没有测试的安全变更，或者一个没有验证策略的任务。对于这些，RRI在基础之上添加固定的惩罚分数。每个惩罚独立应用且仅应用一次，惩罚可以将分数推到100以上。
条件 | +分数
------------------------------------------------|--------
重构 + 同一任务中改变行为 | +8
无测试且高安全/数据影响 (P ≥ 4) | +10
高复杂度和高领域 (C ≥ 4 且 D ≥ 3) | +10
任务涉及认证、授权、权限、敏感内容 | +10
影响超过10个文件 (F ≥ 4) | +8
需要架构或策略决策 | +12
不存在验证策略 | +15
3、从分数到成本
单独的数字不是价值。使RRI有用的是每个分数映射到一个区间，每个区间定义三件事：智能体必须通过的门槛、它运行的模型层级以及任务消耗多少人工审查。
RRI | 标签 | 门槛 | 模型层级 | 人工成本
--------|---------|-------------------------------------------|---------|---------------------------
0–25 | 低 | 自动执行。无需批准。 | 经济 | 无
26–40 | 中等 | 确认受影响区域存在测试。 | 经济 | 最小
41–55 | 中高 | 计划 + 明确的验收标准。 | 均衡 | 审查计划
56–70 | 复杂 | 人类在实施前审查计划。 | 均衡 | 审查计划 + diff
71–85 | 高 | 先分解；运行特征化测试。 | 高级 | 审查分解 + diff
86–100 | 很高 | ADR + 风险分析 + 先分解。 | 高级 | 完整审查
>100 | 过度 | 停止。先进行架构工作。 | 高级 | 架构讨论
ADR是架构决策记录。
复杂性在这里变成成本。RRI 10的任务很便宜：更轻的模型，无需人工审查，少一些仪式。RRI 80的任务成本更高：高级模型、分解、特征化测试、风险分析和人工审查。
将RRI在一个项目中求和本身不会产生交付估计。它不会告诉你项目需要的确切天数。但它确实给你一个风险加权视图，显示成本将集中在何处：模型层级、审查努力、架构关注和验证负担。
这已经比将每个智能体任务视为具有相同的运营成本有用得多。
4、脚本化的现实
我的第一直觉是让智能体给自己评分。那是一个错误。LLM不会一致地计算风险；它们是近似的。让一个模型评估变更的风险，它会给你一个听起来合理的数字，在不同运行之间变化，并且没有问责机制。两个智能体在同一个代码库上对同一个任务评分可以产生不同的数字。这不是风险指标。这是一个多了一步的猜测。
另一个显而易见的路径——MCP服务器、外部API、基于云的评分服务——用一个问题换另一个问题。现在你的风险评估依赖于网络调用、外部服务的正常运行和一个可能过期的凭据。一个告诉你是否可以安全继续的工具不应本身成为一个脆弱的依赖。
所以我把评分移到了一个本地脚本中。它不需要网络，在仓库内运行，并且对其接收的输入是确定性的。脚本（scripts/rri.py）处理数学运算、圈复杂度分析、文件计数、平台配置和评分标准执行。智能体只填写无法完全自动化的输入——例如模糊性、上下文大小和部分测试风险。
以下是它在真实任务上的样子：修改一个Rust项目中的认证库（dubbridge）。智能体为其主观变量提供最佳猜测；脚本处理其余部分。
python3 scripts/rri.py \
--auto-cc \
--touches src/auth/lib.rs \
--D 2 --K 2 --P 0 \
--T 2 --A 1 --X 2
脚本处理输入并产生结构化输出。每行显示变量、应用评分标准底线后的最终分数，以及解释该分数如何得出的证据链。
Platform: rust (auto-detected)
Var Score Source
--- ----- ------
C 1 cargo clippy (max CC 8)
F 0 1 file touched
D 4 rubric floor: auth boundary
T 2 agent-supplied
A 1 agent-supplied
K 4 rubric floor: auth boundary
P 4 rubric floor: auth boundary
X 2 agent-supplied
Base: 42 (weighted sum)
Penalty: +10 (auth boundary, P >= 4)
RRI: 52 Med-high -> plan required before implementation
看看发生了什么。智能体为D、K和P报告了较低的值。它认为这是一个小改动。但文件在认证边界内，所以脚本将这三个都提升到了底线，任务落入了中高区间。
变更的位置否决了智能体的判断。这就是整个想法。智能体不能决定认证代码是简单的。
输出还给你一个运营成本：比最便宜的选项更强的模型、一个实施计划、明确的验收标准和计划的人工审查。这只是一个任务。在一个冲刺中，这给你一些可以预算的东西：不是完美的确定性，但比直觉好得多的信号。
5、为迁移而构建
从一开始，我就想让RRI在不止一个项目上工作。公式、惩罚和区间并不特定于Rust或dubbridge。每个生态系统中改变的两件事是复杂度测量器和锚定评分标准。
在实践中，Cargo.toml意味着Rust，脚本可以使用Rust配置。go.mod意味着Go，可以触发gocyclo。package.json可以触发基于ESLint的配置。pyproject.toml可以触发radon。--platform标志可以在需要时覆盖检测。
评分标准以同样的方式工作。一个通用评分标准可以为**/auth/**、**/migrations/**、**/permissions/**和**/crypto/**等路径提高底线。团队可以在其上叠加项目特定规则，理想情况下由ADR或架构策略支持。
核心分数保持稳定。本地策略适应代码库。
这种可移植性很重要，因为目标不是创建一个完美的通用指标。目标是创建一个可重复的治理机制，可以在不同仓库之间迁移，而不依赖于智能体的心情、信心或推销话术。
6、RRI不解决的问题
RRI是一个护栏，不是正确性证明。
它不保证低RRI任务是安全的。它不证明高RRI任务是困难的。它不替代测试、代码审查、架构判断或领域专业知识。它也不消除所有主观性：模糊性、上下文大小和部分测试风险仍然需要判断。
权重是策略默认值，不是自然定律。它们应该随时间校准。如果一个团队发现迁移始终比默认模型建议的更危险，评分标准应该改变。如果测试密度在特定代码库中是一个糟糕的代理，评分策略应该改变。
RRI还依赖于任务定义的质量。一个模糊的任务可以收到一个分数，但分数不应使模糊性变得可接受。如果验收标准不清楚，模糊性必须提高RRI并迫使在实施前进行澄清。
那个限制不是模型的弱点。它是模型应该暴露的东西之一。
7、实际改变了什么
对我改变最大的不是智能体。是我的角色。
我不再照看每个diff了。现在只有当分数说变更值得人类关注时我才会被拉入。在那条线之下，智能体可以在我不注视每一步的情况下工作。我的时间花在那些人类判断真正重要的少数任务上。
智能体也停止了表现得像一个应声虫。在高分时，工作流放慢：分解任务、写计划、定义验收标准、确定测试，在触及架构之前先询问。
那种分解不仅在安全方面重要。一个从RRI 80拆分成三个低于55的部分的任务不仅仅是更安全的。它还更便宜。更少的模型成本，更少的审查时间，更少的攻击面，更少的隐藏假设。
在RRI之前，"这需要多久？"是用经验、直觉和乐观主义来回答的。RRI并没有完全替代这些。但它增加了一个缺失的具体信号：复杂性、模型成本、审查努力和架构风险可能集中的地方。
"对认证要小心"从来不是一个真正的保障。它存在于记忆和良好意图中，而两者在压力下都会失败。一个有本地策略支持的分数并不完美，但它更难被忽视。一旦复杂性在实施之前是可见的，护栏就不再依赖每个人在正确的时刻记住它。
而智能体项目的成本也不再那么令人惊讶了。
完整实现——scripts/rri.py、锚定评分标准、平台配置和策略——位于github.com/krukmat/dubbridge。
原文链接: How Much Does This Task Actually Cost? A Score for AI Agents
汇智网翻译整理，转载请标明出处