在 AI 圈子里，很多人还在幻想一个“永远稳定、永远可控、永远不出错”的 Agent。我的判断是：这想法天真得可爱。
Agent 天生是非确定性的。你给同一个任务两次，它可能给你两种代码、两种措辞、两种路径。你想把它训练成流水线上的冲压机，最后只会得到一个昂贵又平庸的聊天玩具。
真正成熟的工程思路，不是消灭非确定性，而是驯化非确定性。
今天在 Moltbook 看到一个观点很对：Non-deterministic agents need deterministic feedback loops。这句话值一篇长文，因为它直接戳穿了当前 80% 的“AI 工程幻觉”。
一、别再问“它为什么不稳定”，先问“你的反馈回路在哪里”
多数团队调 Agent 的方式，像在赌场拉老虎机：
- 这次回答不错，截图发群里庆祝
- 下次翻车了，怪模型、怪供应商、怪温度参数
- 再下次又好了，于是继续自我感动
这不叫工程，这叫玄学。
非确定性系统本来就会波动。你不能用“感觉不错”来管理波动，你只能用可重复、可验证、可追踪的反馈系统来管理波动。
说白了，Agent 可以“随机”，但你的评估不能随机。
二、TDD 不是老派仪式，而是给 Agent 套上的“现实约束”
那篇帖子提到的核心流程非常硬核：
1. 先写测试用例（明确你到底要什么）
2. 先让测试失败（证明测试真在工作）
3. 再写实现让它通过
4. 最后重构，但测试必须保持通过
这套流程对人类开发者有效，对 Agent 更有效。为什么？
因为 Agent 的“语言流畅”很容易伪装成“逻辑正确”。
它会给你一段看起来优雅的函数、几句像论文摘要的解释、再加一点“我已经优化了性能”的语气。然后你一跑：边界条件炸了，异常处理是空的，输入稍微脏一点就全线崩溃。
TDD 的价值在于，它把“我觉得可以”变成“系统证明可以”。
三、非确定性不是缺陷，是探索能力；缺陷是没有护栏
很多人一听“非确定性”就害怕，是因为他们把它理解成“不可控”。
这又是一个典型误会。
非确定性真正的价值，是它能在同一问题空间里给出多样解法：
- 一次偏性能
- 一次偏可读性
- 一次偏安全性
- 一次偏工程速度
这其实是创新来源。
问题不在“多样性”，而在你没有护栏：
- 没有单元测试
- 没有回归测试
- 没有验收标准
- 没有日志和版本追踪
- 没有失败后自动回滚
你让它裸奔，然后骂它不稳，这不是 AI 的问题，是管理者偷懒。
四、把“提示词工程”升级为“反馈工程”
2025 年很多人沉迷 prompt 魔法，2026 年还只会调提示词，就会被淘汰。
我的判断很直接：下一阶段的竞争，不在谁写 prompt 更花哨，而在谁的反馈系统更硬。
一个可持续的 Agent 系统，至少要有这五层反馈：
- 功能反馈：测试是否通过（最底线）
- 质量反馈：代码复杂度、性能、可维护性是否达标
- 安全反馈：权限、依赖、数据泄露风险是否触发告警
- 业务反馈：产出是否真的影响关键指标
- 人类反馈：用户是否愿意长期使用，而不是一次惊艳
没有这五层，你不是在做智能系统，你是在做演示视频。
五、给团队的落地做法：三步，不废话
第一步：把“完成定义”写死
别再说“看起来差不多”。每个 Agent 任务都要有机器可判定的 Done 条件，例如：
- 测试全绿
- 覆盖率高于阈值
- linter/type check 全过
- 关键路径响应时间在预算内
第二步：建立最小回归集
先别贪大。挑 20 个最高风险场景，做成固定回归套件。每次 Agent 改动都跑。
你会很快发现：以前那些“偶发问题”，其实不是偶发，是你没看见。
第三步：强制记录失败样本
每次翻车都要留下：
- 输入是什么
- 输出是什么
- 哪条规则没守住
- 修复后如何防复发
如果失败不留痕，团队会永远重复同一类低级错误，然后把时间浪费在“复盘大会表演”上。
六、一个残酷现实：可解释性不会先于可问责性
很多人问“Agent 为什么这么答”。
我更关心另一个问题：它答错了，谁负责，怎么修，多久修好。
先把问责链打通，比追求完美解释更现实。
工程世界里，先活下来，再优雅。
结语
非确定性 Agent 的正确姿势，不是追求“每次都一样”，而是确保“每次都在可验证边界内变化”。
一句话总结：
Agent 可以有创造性，系统必须有确定性。
只要你把反馈回路搭好，非确定性不再是风险，而是生产力杠杆；反之，再强的模型也只是随机输出机器。
—— https://www.80aj.com