最近，我让 AI 帮我润色一篇博客文章。
它写得很快。结构完整，思路清晰。当我说希望它听起来更专业时，它补充了技术讨论。当我要求学术支撑时，它找到了近期的论文。
文章变得越来越严肃，但我开始犹豫：它真的需要这样写吗？
内容上没有什么明显的问题。但我原本想写的是一篇带有我自己声音的文章，一篇能让读者看到我如何思考一个问题的文章。经过几轮修改，它逐渐变成了一篇我自己都需要花时间消化的研究综述。
我的期望也在过程中不断变化。一开始，我并没有完全想清楚对于这篇特定的文章，“专业”或“深入”应该意味着什么。
那次经历让我重新思考什么造就了一个好的智能体。
如果我逐条核对要求，我们的协作已经完成了相当多的事情：文章写好了，研究做了，参考文献也到位了。每一个单独的要求都有对应的交付物。
但当我把它们放在一起时，我仍然要问：这是我想发表的文章吗？
检查一个智能体做了什么很容易。解释这些行动是否让用户更接近他们的目标则需要更多功夫。
在这个案例中，“补充学术支撑”是一个明确的要求。其目的是让论证更可信。如果补充研究导致文章失去了原本的声音，我们就需要重新考虑如何使用这些材料。
用户的新要求并不总是简单地叠加在上面。它可能是方向的修正，甚至是删除已完成工作的理由。
对于一个持续参与任务的智能体来说，理解这些变化会影响整个协作的质量。它需要在反馈到来时修正对任务的理解，而不是不断地往结果上添加更多内容。
这也让“完成”变得更加复杂。文章可能有结尾，任务可能被标记为完成，而用户仍然没有拿到可以用的东西。
所以在设计评估之前，我想先厘清另一件事：我们想从结果中做出什么判断？
检查事实准确性意味着核实引用和支持性证据。评估修改能力意味着观察智能体是否理解反馈并保留仍然有效的内容。判断它能否从头到尾承担一项任务，还意味着要看它给用户留下了多少工作。
这些问题相互关联，但“整体质量不错”几乎无法回答它们中的任何一个。
只有当我们清楚自己在评估什么时，我们才知道该收集什么证据，以及一个分数能告诉我们多少。
评估还需要对当时的情况保持公平。
在这个写作过程中，有些目标只有通过讨论才变得清晰。早期的回应应该根据已经表达的需求来评判，而不是后来才出现的偏好。
如果要求已经明确而结果仍然不合适，我们需要更精确地定位问题。是智能体误解了？是它忘记了先前的约束？还是满足一个新要求破坏了原本已经奏效的东西？
所有这些都可能被描述为“写得不好”，但它们需要非常不同的改进。提供更多任务信息、调整上下文，或改变执行方式，都可能有所帮助。但首先，我们需要知道问题出在哪里。
其他要求不应随个人偏好而改变。引用是否真实、事实是否准确、结论是否有支撑，必须独立核查。用户喜欢一个结果，不足以证明这些要求已经满足。
我认为这种区分很重要。它让评估既能顾及具体需求，又能保留必要的判断标准。
即使目标清晰、智能体这次做对了，仍然有更多值得观察的地方。
它能第二次把同样的任务做好吗？如果用户换一种说法提出要求，它会误读意图吗？当信息缺失时，它能承认不确定性，而不是用流畅的文字填补空白吗？
一项关于智能体可靠性的研究分别考察了一致性、鲁棒性、可预测性和安全性。在它所测试的模型和基准上，能力的提升只带来了有限的可靠性改善。这提醒我们，在了解一个智能体能完成什么之后，我们仍然需要理解在什么条件下我们可以依赖它。相关研究
那么，谁有权定义一个好的智能体？
我认为用户的真实目的应该是出发点。产品团队需要清楚他们打算服务哪些需求，以及他们将承担多少责任。工程团队需要理解实现方式和系统能力的边界。评估把这些期望放入具体情境中，检验结果是否印证了它们。
需要有人对最终的权衡负责，也需要有证据作为讨论这些权衡的基础。
以“更专业”这个要求为例。一个人想到的是术语和参考文献。另一个人想到的是更严谨的推理。还有人期望作者能直击问题的核心。当我们把这个要求应用到一篇实际的文章上时，就更容易看出我们说的并不是同一件事。
我更愿意通过这样的案例来建立共识。哪些事实必须正确？哪些部分影响结果是否可用？哪里有不同的选择空间？所有这些都可以讨论。我们的标准越具体，日后解释分歧的机会就越大。
这些标准也应该可以修订。新的情况可能暴露出我们未曾考虑的问题，用户也可能开始提出不同的要求。重要的是记录我们做出调整的原因，这样团队才能区分产品的改进与评判方式的改变。
评估的价值还需要体现在我们之后做出的选择中。
如果一次评估让我们更清楚该优先做什么、能够解释为什么某项改进值得投入，并且知道在证据不足时需要哪些额外的测试，那么这些分数就有了实际价值。
回过头看，AI 确实帮我让文章更完整了。是后来几轮的讨论帮助我们弄清了哪些该保留、哪些可以删去。
这也是我希望评估能帮助团队做到的事：当一个结果看起来已经不错时，仍然有办法判断它是否准备好交到用户手中，以及我们为什么能对这个判断有信心。