Agent 系统的不确定性治理：当软件工程遭遇"梯度下降" - 张善友
内容提要
本文探讨Agent系统评测难题：传统软件调用链编译期确定，而Agent工具调用运行时涌现，缺乏绝对正确性参照。核心挑战是任务目标不可计算，需用代理指标近似，但方向可能偏差。工程策略非求解而是约束：用确定性DAG骨架封装不确定性，为Skill定义多维评估向量，并插入可判定的Reflection Gate。最终目标非全局最优，而是预算内“足够好且可解释”的满意解，强调可靠性胜过聪明。
延伸解读
从“正确性”到“评估函数”的范式转变
传统软件在编译期就确定了调用链，因此可以用断言来验证正确性。而Agent的工具调用在运行时才涌现，失去了绝对正确性的参照，必须引入评估函数来近似“上帝视角”。这意味着Agent系统的质量保障不再是简单的测试，而是需要设计合理的损失函数，这给工程实践带来了根本性的挑战。
代理指标的陷阱：优化方向可能偏离真实目标
由于Agent任务的ground truth往往不可计算，当前只能使用代理指标（如BLEU、用户满意度等）来逼近真实目标。但代理指标优化的方向可能与真实目标不一致，就像用“代码行数”考核程序员一样，指标好看但结果未必好。因此，在设计评估体系时，需要警惕代理指标的局限性，并尽可能使其与业务目标对齐。
用“约束”代替“求解”：三条可落地的工程路径
面对不可计算的真实目标，工程策略不是求解，而是约束。具体路径包括：用确定性DAG骨架封装不确定性，将全局优化降维为局部生成；为每个Skill定义多维评估向量，类似企业KPI体系；在关键节点插入可判定的Reflection Gate，将全局不确定问题拆解为局部可验证的决策。这些方法旨在将不确定性限制在可控范围内。
满意解优于最优解：可靠性比聪明更重要
Agent系统可能不需要收敛到全局最优，而是追求预算内“足够好且可解释”的满意解，这与赫伯特·西蒙的有限理性理论相呼应。因此，评测的核心指标不应只是准确率，而应是可靠性、可解释性和预算内完成度。对于企业级数字员工平台而言，这些属性比“聪明”更关键，因为它们直接关系到系统的可信赖程度。
Q&A
Agent系统与传统软件在工具调用链上有什么本质区别？
传统软件的调用链在编译期就已确定，输入决定调用，调用决定输出；而Agent系统的工具调用是在运行时涌现的，具有不确定性。
为什么Agent系统的评测需要引入损失函数？
因为Agent系统失去了传统软件中绝对正确性的参照系，无法用上帝视角的断言来测试，所以需要引入评估函数来近似上帝视角，这就是损失函数在Agent语境下的含义。
Agent评测中的损失函数难题分为哪三个层次？
分为三个层次：意图对齐（感知层）、任务分解（规划层）、工具调用验证（执行层）。分别对应MetaSkill DAG的触发条件、拓扑结构和节点监控。
为什么Agent任务的ground truth往往不可计算？
因为Agent任务的目标往往没有闭式表达，无法直接计算，只能使用代理指标来近似，但代理指标的优化方向可能与真实目标不一致。
面对不可计算的真实目标，工程上采取了哪些约束策略？
三条策略：1. 用确定性DAG骨架封装不确定性；2. 为每个Skill定义多维评估向量；3. 在关键节点插入可判定的Reflection Gate。
Agent系统追求的目标是什么？为什么不是全局最优？
Agent系统追求的是预算内'足够好且可解释'的满意解，而不是全局最优。因为Agent系统可能根本不需要收敛到全局最优，而是在资源约束下做出决策，这与Herbert Simon的有限理性理论呼应。
Agent系统评测的核心指标应该是什么？
核心指标是可靠性、可解释性和预算内完成度，而不是单纯追求准确率。这些是企业级数字员工平台最需要的工程属性。
如何理解Agent系统的不确定性？
Agent系统的不确定性不是bug，而是feature。它来自LLM的生成本质和人类意图的固有模糊性，无法消除，但可以通过有效治理来管理。工程成熟度取决于不确定性是否被有效治理。
