AI 软件应该怎样设计?-夜雨聆风

AI 软件应该怎样设计?

把概率模型放进确定性外壳：AI 负责理解模糊信息，传统软件负责权限、状态、硬规则与执行。先证明低风险闭环，再逐步提高自主程度。

做 AI 产品最容易犯的错误，是把模型的能力当成整个系统的能力。

模型能正确回答十个演示问题，不代表产品能稳定处理一万次真实任务。它可能误解意图、忽略规则、调用错误工具，也可能在信息不足时自信地继续执行。

这不是说模型不能用于严肃工作，而是产品必须为不确定性而设计。

传统软件追求同样输入得到同样结果。大模型的价值恰好来自它能够处理无法完全写成规则的输入。好的 AI 软件不会强迫其中一方取代另一方，而会让它们各自负责擅长的部分。

概率核心，确定性外壳

可以把 Agent 看成一个概率核心，外面包着确定性系统。

模型负责理解邮件、识别意图、比较非结构化材料、提出计划和选择工具。

传统系统负责身份、余额、业务状态、权限、金额上限、必经审批、数据写入和最终交易。

例如，模型可以判断客户大概率符合退款条件，但退款金额计算、可退商品范围、支付渠道和审批阈值应该由代码校验。模型可以提出执行动作，确定性工具决定它是否被允许。

不要把硬规则只写进提示词。提示词是指导，不是保险柜。

产品团队常把“全自动”当成终点，甚至当成第一版卖点。

更实际的方法，是选择能够创造价值的最低自主程度：

自主程度越高，节省的人力越多，错误的潜在损失也越大。

所以升级依据不应该是模型发布了新版本，而应该是评测和运行数据证明：在某类明确场景中，完成率、误操作率和异常识别已经达到可接受水平。

查询订单和删除订单，不应该拥有相同的调用门槛。

可以把工具分成只读、可恢复写入、高影响写入和不可逆行动。风险越高，输入校验、审批要求、限额和监控越严格。

每个工具还需要满足几个工程条件：

Agent 的可靠性很大程度上来自工具设计，而不只是提示词写得多详细。

没有评测，团队只能靠聊天记录挑选成功案例。

第一批评测任务可以来自真实历史：最常见的请求、最昂贵的错误、最容易混淆的边界，以及过去需要资深员工介入的例外。

每个任务要有可检查的成功条件。除了回答是否正确，还要检查工具选择、参数、是否越权、是否在该停的时候停下，以及最终业务状态是否正确。

OpenAI 在介绍 Agent 评测时强调，评测不只是上线前考试，也是持续开发的一部分。模型、提示词、工具和知识变化后，都应回归同一组关键任务。

很多团队把转人工率视为越低越好。这会诱导系统在不确定时冒险继续。

可靠 Agent 应该知道自己何时不够确定。高风险行动、规则冲突、缺少关键信息、连续工具失败和用户明确要求，都可以成为交给人的条件。

关键不只是“转人工”，而是顺利交接：把目标、已读信息、已经尝试的步骤、失败原因和建议下一步一起交给人。否则，用户只是被迫重新解释一遍。

Agent 运行需要一套操作控制台。

团队要能看到任务处在哪一步、调用了什么工具、成本和耗时、为何停下。异常可以暂停，错误行动可以撤回，同类事故能够被加入评测集。

这套能力不显眼，却决定产品能否从演示走向生产。

好的 AI 软件不是假装模型永远正确，而是假设它迟早会犯错，并让错误在造成严重后果前被发现。

每做一个 Agent 场景，都可以先回答：

如果这些问题没有答案，再漂亮的对话界面也只是一个风险更高的原型。

当产品开始替客户完成工作，下一个必须改变的是收费方式。下一篇讨论：按账号收费的 SaaS 模式会消失吗？

https://openai.com/business/guides-and-resources/a-practical-guide-to-building-ai-agents/

https://openai.com/index/evals-drive-next-chapter-of-ai/

https://openai.com/index/designing-agents-to-resist-prompt-injection/