给翻译流程加个质检 Agent：工具调用设计的三条原则

上一篇文章聊了 Agent 的放权设计，这次落到一个具体场景：给翻译流水线加质检环节时，工具调用层怎么设计才不返工。

原则一：工具粒度对齐「撤销单元」

质检 Agent 可用的工具：改术语、调语序、标记人工复核。设计时每个工具的粒度必须等于一个「可独立撤销的变更单元」。早期版本我们有个「批量修正」工具，一次改 20 处——后来发现第 3 处改错时无法只回滚第 3 处，只能整批撤销重来。拆成单点工具后，误改的代价从「重来」降到「改回一处」。

原则二：只读探查免费，写入探查收费

Agent 判断「要不要改」之前需要探查上下文：查术语表、查历史译文、查领域词频。这些只读工具应该无限量供给（缓存 + 不产生副作用），让 Agent 充分侦察后再动手；而所有写入类工具设置预算（每个任务最多 N 次修改调用），超预算强制转人工。这个不对称设计能防住 Agent 的「完美主义循环」——反复小改不停。

原则三：错误码说人话，别让 Agent 猜

工具返回的错误信息是给模型看的提示词。早期我们的工具报错是标准的 HTTP 风格：400: invalid param。Agent 的反应是反复重试同样的调用。改成描述性错误后（「术语表中不存在『句柄』的英文对应，建议先调用 term_lookup 确认可用译名」），Agent 的一次纠错成功率从 40% 提到 85%。给模型的错误信息要包含「下一步该做什么」，这是工具设计里回报率最高的一件事。

一个反直觉的结论

质检环节加入 Agent 后，我们统计自动化改动的接受率：Agent 单点修改的接受率（89%）反而高于人工批量修改（76%）——因为单点修改每处都有独立的判断依据，而批量修改常被「顺手改」拖累。工具粒度做小，不只是为了好撤销，还逼着每一次修改都有明确理由。

结语

工具调用层是 Agent 能力的放大器也是紧箍咒。粒度对齐撤销单元、读写不对称预算、错误信息可行动——三条原则的共同目标是：让 Agent 的每个动作都可追溯、可撤销、有预算。