稳定的季军
评价一个 AI 产品时，我们是不是太容易关注它的最高分了。
一个 Coding Agent，也就是能读写代码、调用工具的编程智能体，独立完成了一次复杂重构；一个模型解出了一道过去怎么都解不出的问题；一个 Agent 连续工作几个小时，完成了原本需要工程师一天才能做完的任务。
这些时刻很容易让人兴奋。它们像比赛里的冠军，让我们看见能力的上限。
但把 AI 真正放进工作里，还有一个不那么耀眼、却可能更重要的问题：它能不能稳定地拿季军？
什么叫“稳定的季军”
这里的“季军”，不是说第三名就够了，也不是主动放弃第一名。我借这个名次描述一种表现：结果已经相当不错，足够使用，也能真正交付出去。
所以，“季军”指向的不是能力上限，而是我希望能够依赖的质量下限。更重要的是前面的两个字：稳定。
今天给一个人一道题，他拿了第三名。明天换一道题，他又拿了第三名。下周遇到一个没见过、但仍然属于他能力范围的问题，他还是能把事情做出来。
这不是把同一道题重复做一百遍，都得到同一个答案。而是面对不断变化的新任务，结果依然不会轻易掉出可以接受的区间。
假设我是教练，手里有两个选手。
第一个可能拿冠军，也可能第五、第十，然后下一场突然又拿冠军。第二个很少夺冠，但长期是第二、第三、第三、第四、第三。
只看集锦，第一个一定更耀眼。但如果要打一个漫长的赛季，第二个身上有一种很宝贵的东西：我知道把事情交给他，大概会得到什么。
日语里有一个我很喜欢的说法，叫「計算が立つ」，意思是可以预估、心里有数。用来形容选手时，是说教练知道把他放上场，大概能贡献多少。
这种可预测性，本身就是一种能力。
Workflow 的限制也是产品的一部分
这也是 Workflow，也就是预先编排的工作流，与 AI 结合的一种价值。以 Dify 中由人编排的流程为例，相比能自己决定下一步的 Agent，它显得有点“笨”。
你需要提前告诉它第一步做什么、第二步做什么；什么情况下走 A，什么情况下走 B；哪里调用工具，哪里检查结果，什么数据能进入下一步。必要时，还要在关键节点插入人工确认。
它的自由度被人为限制了。
这些限制看起来像能力上的妥协，但限制本来就是产品的一部分。固定步骤、约束输入输出、限制工具、加入判断条件，目的通常不是让 AI 偶尔给出一个谁都没想到的天才答案，而是减少结果的波动。
假设一个自由探索的 Agent，表现会在 50 分到 100 分之间波动。设计得当的 Workflow，可能把它收窄到 70 分到 85 分。
它可能失去一部分拿 100 分的机会，也减少突然掉到 50 分的概率：用一部分上限，换取更高的下限。
不过，流程固定不等于结果可靠。检查条件写错了，或者流程没有覆盖某类输入，系统也可能稳定地犯错。下限有没有提高，仍然要靠真实任务验证。
对于生产环境，这种可预测性可能比偶尔的高分更重要。企业真正害怕的，往往不是 AI 不够聪明，而是：我不知道它下一次会做什么。
Coding Agent 还有一个变量：教练
Codex、Claude Code 这样的 Coding Agent，让我着迷的地方，恰恰是它们有机会拿冠军。
面对复杂问题，你可以把代码库、需求和上下文交给它，再不断沟通、调整方向、检查结果。有时候，它会做出远超预期的成果。这和沿着预设流程执行任务，是很不一样的体验。
但这里有一个容易被忽略的变量：教练。
同一个 Coding Agent，放在不同的人手里，最后的结果可能完全不同。好的工程师知道什么时候让它自己探索，什么时候打断；知道该给什么上下文，结果哪里看起来不太对；也知道什么时候应该修改问题本身，而不是继续修改提示词。
因此，最终表现并不只取决于 Agent。有一部分能力存在于 Human-Agent Loop，也就是人与 Agent 反复执行、检查和调整的协作过程里。
选手底子很好，教练也要能判断场上的情况。优秀的教练可以带着它不断冲击冠军；教练如果不知道自己在做什么，再强的选手也可能跑偏。
而教练做的也不只是帮助它冲高分。及时发现错误、缩小任务范围、要求验证，同样是在守住下限。
它们侧重的目标不同
这样看，“Dify 和 Coding Agent 到底谁更先进”就不太是一个有用的问题。这里比较的，其实是两种使用方式的侧重。
预先编排的 Workflow 更强调：在大量重复发生、但具体内容不断变化的任务中，维持一个足够可靠的质量下限。
由人带着探索的 Coding Agent，则给模型更多临场决定的空间，让使用者有机会得到一些没有提前定义好的结果。
一个更关心“下一次还能不能做到”，另一个更愿意探索“这一次到底能做到多好”。两件事都很有价值。
这不是产品之间不可跨越的边界。Workflow 可以在某个环节调用 Agent，Coding Agent 也可以通过固定步骤、测试和人工确认提高稳定性。
什么时候应该追求冠军
“稳定的季军”并不意味着所有 AI 都应该被做成 Workflow。如果拿冠军的收益很高，而失败成本又低，我当然愿意接受波动。
Coding Agent 有一个很有利的条件：如果开发环境可以快速重建，它就有很大的试错空间。
Agent 写错一段代码，我可以看 diff，也就是代码差异，可以跑测试、回退改动。在与生产隔离、可以快速重建的开发环境里，即使把环境搞坏了，也可以重建后再试一次。
重来不是没有成本，但如果恢复足够快，我就更愿意让它大胆探索。它一旦成功完成一次复杂重构，可能直接替我省下几个小时。在这个范围内，我甚至愿意接受它偶尔拿第十名，因为冠军带来的收益可能覆盖试错成本。
但公司不是开发环境，不能搞坏了，快速重建一个就当作什么都没发生。
付错的钱要追回，发给客户的错误信息要解释，已经影响的信任也不会随着系统重建而恢复。假设一个 AI Workflow 每天处理一万笔业务，一次异常就可能导致这样的后果，那么偶尔表现惊艳，并不能抵消这些损失。
这也划出了 Coding Agent 的边界：环境可以重建，不代表代码造成的后果可以撤销。一旦它能直接操作生产数据，或者改动未经充分验证就进入业务，失败就未必便宜。
这时候真正值钱的是：我知道它明天大概率还是第三名。识别异常、拦住有风险的操作、在必要时交给人处理，都是为了守住这个可以依赖的质量下限。
不要只看最好的一次
我们谈论 AI 时，仍然很容易被最好的一次吸引：榜单上的高分、Demo 中最漂亮的路径、社交媒体上最惊艳的案例。
这些东西很重要，它们让我们看见技术边界正在往哪里移动。但只盯着漂亮的分数和成功案例，很容易忽略任务之间的差异，以及失败发生在什么地方。
当 AI 从 Demo 进入真正的工作，它最差的时候，会差到哪里？
以及，下一件事情交给它，我知道自己大概会得到什么吗？
一个成熟的 AI 产品，不一定每次都要拿冠军。有时候，更难的事情是，面对下一道没见过的题，依然能稳定地拿季军。