夜雨聆风导语：过去二十年，SaaS 有两个入口：人点网页，机器调 API。现在第三个入口正在出现——Agent 不看漂亮的控制台，也不会仅凭接口名称理解业务。它需要技能、文档、规则、失败回退和权限边界。过去最没人愿意维护的那堆文字，正在成为一套产品最重要的新界面。
想象 Stripe 控制台的未来。
今天，人登录网页，看表格、点按钮、查图表；程序通过 API 创建支付、退款、拉取账单。
如果以后大部分操作由 Agent 完成，它走哪扇门？
不是网页，也不是 App 的 UI。Agent 不在乎按钮是圆角还是直角。
也不只是 API。API 只告诉它有哪些动作，并不告诉它什么情况下该做、先做哪个、失败了怎么办。
Bret Taylor 在 Cheeky Pint 里为第三扇门用了一个词：
Agent harness
他描述的不是一组更漂亮的接口，而是围绕产品提供的技能、文档、规则和使用方法。
一句话区分：
API 说明“你能调用什么”；harness 说明“你该怎样用这些能力，把一件事安全地办成”。
过去，这两者之间的空白由人补上。
工程师读 API 文档，顺手把业务常识带进代码。一个财务人员知道退款前该先确认哪几项，一个客服主管知道什么请求必须升级。
Agent 不会自动继承这些隐性知识。你没有写出来的规则，对它来说就不存在。
一、为什么“接口齐全”仍然会把事情办砸
假设一个支付 API 提供三项能力：
•查询订单；•发起退款；•关闭争议。
从技术上看，已经够用了。
但一个能处理售后纠纷的 Agent 还需要知道：
•先核对订单归属，再判断退款资格；•超过某个金额必须人工确认；•争议处理中不能直接关闭订单；•接口超时不能简单重试，避免重复退款；•用户提供的订单号置信度低时，必须复述确认。
这些都不是新 API。
它们是使用 API 的判断结构。
没有 harness，Agent 可能每一步都调用成功，整件事却办得完全错误。日志里一片绿色，客户的钱退错了。
传统软件时代，产品把隐性知识藏在人脑和实施手册里还勉强能运转；Agent 时代，这些知识必须变成机器可读、可检查、可更新的产品资产。
二、Braintrust 为什么把 harness 单独算作第六代
2026 年 5 月，Braintrust 发布了一篇很扎实的文章，把 Agent 架构拆成六代：
1.单次 prompt；2.固定链式流程；3.ReAct 循环；4.显式工作流图；5.现代 Agent loop；6.AI harness。
前五代主要在改变 Agent 如何思考和行动。
第六代把注意力挪到模型周围：工具、记忆、技能、权限、沙箱、持久状态，以及把这些东西约束在一起的整套环境。
Braintrust 有一句判断很重要：
当实现 AI 功能越来越便宜，仍然昂贵的，是判断新版是否比旧版更好。答案活在 eval 里。
这句话也解释了为什么 harness 不是“文档打包”。
一套合格的 harness 至少要同时包含：
•能力：能调用什么；•策略：什么时候调用；•边界：什么绝不能做；•状态：现在做到哪一步；•反馈：怎样知道做对了；•恢复：失败后如何退回安全位置。
如果没有最后两项，它只是说明书，不是可运行的交付环境。
三、UI 设计正在分叉
人和 Agent 使用产品时，需要的东西几乎相反。
人需要少读文字、减少选择、获得及时提示。
Agent 需要明确文字、稳定结构、尽量少的隐含语义。
这意味着，未来很多产品会同时拥有两套设计系统：
•一套设计“人看见什么”；•一套设计“Agent 理解什么”。
第二套不一定有视觉界面，却会像 UI 一样决定体验。
一个字段命名含糊，一条规则藏在 PDF 第 47 页，一次失败只返回 unknown error，对 Agent 来说都相当于把按钮放到了屏幕外面。
机器界面也会有可用性问题，只是它的“用户抱怨”表现为工具乱调、轨迹绕圈和静默失败。
四、语音产品里，harness 比模型更接近结果
语音链路里有一个特别典型的例子：ASR 置信度。
普通 API 返回一段文字：
订单号 INV-4493。
模型看到的是一个完整、通顺、可执行的事实。
但如果真实输入是 INV-4492，而且最后一位的识别置信度只有 0.4，正确的产品行为不是立刻查库，而是：
我确认一下，最后一位是 2 还是 3？
这一步不需要更聪明的大模型。
它需要产品把“这段识别有多可信”与“低置信时该做什么”一起交给 Agent。
类似的还有：
•检测到用户可能没说完时，不要抢话；•背景声疑似另一名说话者时，不要切断当前回复；•调用改约接口前，先复述日期并得到确认；•涉及赔偿承诺时，必须进入人工关卡；•TTS 已经开始播报后，哪些内容仍可安全中断。
这些规则加起来，就是语音 Agent 的 harness。
同一个底层模型，是否拥有这套环境，结果可以差一个产品代际。
五、产品文档会升值，也会暴露你
过去，写文档常被当成发布后的收尾工作。
Agent 时代，文档会前移到产品定义：如果一项能力无法被准确描述、无法给出例子和边界，它就很难被 Agent 稳定使用。
这会带来一个不太舒服的好处：它迫使团队把原本只存在于老员工脑子里的手艺写出来。
也会带来一个真实风险：写得越清楚，替换你的成本可能越低。
当不同供应商都提供结构相似的 harness，Agent 可以更容易比较、切换和组合能力。你今天靠“客户不知道怎样迁移”形成的锁定，会变薄。
但不提供也不是防御。
如果你的产品无法被 Agent 理解，它很可能不是更难替换，而是先被绕开。Agent 会去找那个文档清楚、错误可读、权限明确的替代品。
在机器成为用户之后，难用不再制造粘性，只制造路由绕行。
六、还有一类产品可能比 UI 更耐久
Bret 在同一场讨论里区分了两类系统：
•ledger：账本本身就是价值，例如支付流水、总账、合同原件；•engagement：价值主要来自交互，例如客服后台、营销工作台。
Agent 最先削弱的，很可能是后一类。
过去，数据集中在一个界面里很重要，因为人不愿在十个系统间切换。Agent 可以同时从十个地方取数据，统一界面的优势会下降。
但总账不会因为 Agent 会抓数据就失去法律意义，支付流水也不会。
这给产品战略一个更深的提醒：
如果你的产品价值主要来自“人每天登录这个产品来工作”，Agent 既是新用户，也可能是绕过你的力量。
你需要么成为不可替代的记录，要么提供最适合 Agent 使用的 harness。只靠一个好看的工作台，耐久性会越来越弱。
七、我会怎样检查一套产品是否准备好给 Agent 用
我会让一个完全不了解产品的 Agent 完成真实任务，然后只看五件事：
1.它能否发现正确能力，而不是猜接口；2.它是否知道调用前置条件；3.它能否解释自己为什么这样做；4.失败后是否回到安全状态；5.它完成的结果能否被独立评测。
如果它需要一个工程师在旁边不断补充“这里其实应该……”，那些口头补充就是产品缺失的 harness。
把它们记录下来，比再做一版控制台更接近下一代产品。
写在最后
软件工程师一直不喜欢写文档。
但是未来可能是，AI 写掉了越来越多代码，却让人把更多时间花在说明意图、规则和边界上。
这不是生产力倒退。它只是把过去藏在代码与人脑里的东西，搬到了决定 Agent 行为的位置。
网页是给眼睛的 UI，API 是给程序的 UI。
接下来那套技能、文档、规则、评测和失败回退，会成为 Agent 的 UI。
当机器开始使用你的产品，文档就不再是产品的说明书。文档本身，就是产品。
姚光华 Colin 写于 2026.7
References
[1] The six generations of AI agents and how to eval them: https://www.braintrust.dev/blog/six-generations-ai-agents