先看证据
一场被简化的归因：GPT-6.1 Sol 与 DevRev 的绑定叙事
2026 年 11 月 4 日，OpenAI 官网发布了一则客户故事，标题直指“DevRev 用 GPT-6.1 Sol 实现自主自助服务”。故事中，DevRev 首席技术官 Ahmed Bashir 解释了公司如何将 OpenAI 模型与自研的 Harness 结合，让 Computer 和 Operator 两个代理产品能够推理实时数据、执行可逆操作，并让答案回溯到来源。这听起来像是一次典型的模型厂商与 SaaS 厂商的联合背书：前沿模型提供推理能力，垂直厂商提供业务上下文和权限控制。
但细读公开材料会发现，归因被简化了。DevRev 在 2026 年 9 月 29 日的合作公告中只写了“使用 OpenAI 的模型”，并未点名 GPT-6.1 Sol；Agent Studio 和 Computer 的文档也没有披露具体模型型号或路由策略。OpenAI 的客户故事是首个将 GPT-6.1 Sol 与 DevRev 直接关联的公开文本，但它来自模型厂商的营销页面，而非 DevRev 的技术文档或独立评测。这意味着，“GPT-6.1 Sol 驱动 Computer 和 Operator”目前只是一个未经 DevRev 官方确认的强归因。对于技术负责人而言，这个细节很重要：它提醒我们，在评估此类合作时，需要区分“厂商联合叙事”与“可复现的技术事实”。
那么，为什么这个被简化的归因仍然值得读？因为 DevRev 的架构选择——用私有 Harness 连接企业知识、权限和操作——代表了一类正在成型的企业级代理设计模式。无论底层是 GPT-6.1 Sol 还是其他模型，这种模式都在试图解决同一个问题：如何让大模型的推理能力在受控的企业环境中产生可审计、可回滚的业务结果。而 DevRev 公开的 Enterprise-Bench 指标和 BILL 的 PoC 数据，恰好为我们提供了一个讨论的锚点，尽管这些数字本身需要谨慎对待。
Harness 如何把模型能力转化为企业工作流
DevRev 的 Harness 是一个连接企业知识、强制执行权限、并控制代理可执行动作的软件层。根据公开文档，Computer 的工作流程大致是：代理首先检索配置的工作区知识，结合用户身份、权限和业务上下文决定下一步；如果需要操作，则通过工具、技能或工作流执行，例如创建工单、更新记录或启动审批；遇到权限、判断或例外问题，则请求人工介入。这种设计的关键在于，模型并不直接接触原始数据库或执行系统，而是通过 Harness 提供的抽象接口进行推理和行动。
Agent Studio 进一步允许用户用对话描述工具行为，并用固定规则定义部分逻辑。这实际上是在模型推理和确定性规则之间做混合：对于难以用规则穷举的复杂判断，交给模型；对于必须严格控制的步骤，用规则锁死。Ahmed Bashir 在采访中提到，DevRev 希望构建者能够“用对话描述更多逻辑，并为每个任务选择合适类型的智能”。这暗示了未来的方向是更细粒度的模型路由——简单任务用低成本模型或规则，复杂任务用高推理模型。但公开材料并未披露当前的具体路由策略，也没有说明 GPT-6.1 Sol 在哪个环节被调用。
从企业采购的角度看，这种 Harness 架构的价值在于它把“模型能力”封装成了“可审计的服务”。每个动作是可逆的，每个答案都指向来源，权限由企业自己的系统强制执行。这意味着，即使底层模型出现幻觉或错误，Harness 也能提供回滚和追责的路径。对于技术负责人来说，这比模型在某个基准上的分数更有实际意义：它决定了代理能否被安全地部署到生产环境。
数字背后的证据强度：48%、4.4 倍与 70%
DevRev 在合作公告中给出了几个引人注目的数字。在 Enterprise-Bench 测试中，Computer 的准确率比一个“领先 AI 模型”高 48%，同时每个正确回答使用的 token 数比对照系统少 4.4 倍。此外，在客户 BILL 的真实查询概念验证中，AI 解决率达到 70%。这些数字如果成立，确实能说明 DevRev 的 Harness 在结合企业上下文和权限后，显著提升了模型的实用效率。
但证据强度需要仔细掂量。首先，Enterprise-Bench 是 DevRev 自建的基准，评估的是“数据有多版本、信息分散在不同系统、访问依赖角色”的场景。公告没有给出样本量、任务明细或完整评测方法，也没有点名那个“领先 AI 模型”是谁。这意味着 48% 和 4.4 倍无法被独立复现或横向比较。其次，70% 的解决率明确来自单客户 BILL 的概念验证，不是生产环境的长期数据，也不能外推到其他企业。概念验证通常经过精心挑选的任务和理想化的配置，与真实运营中的长尾请求、权限冲突和系统故障有本质区别。
从技术负责人的视角，这些数字的用途不是直接采信，而是作为提问的起点：Enterprise-Bench 的任务分布是否覆盖了你们企业的典型场景？token 消耗的对比是否包含了重试和失败请求？70% 的解决率中，有多少是简单查询，多少是复杂操作？如果这些问题没有答案，那么这些数字就只能视为厂商的营销素材，而非采购决策的依据。DevRev 的架构思路值得借鉴，但其效果宣称需要在自己的环境中验证。
成本平衡的另一面：模型定价与生态依赖
OpenAI 公布 GPT-6.1 Sol 的标准 API 价格为每百万输入 token 2 美元、输出 10 美元，并称其标准输入输出 token 价格为 GPT-6 Astra 的五分之一。Ahmed Bashir 在采访中强调，DevRev 看重的是“推理能力、可信度、对齐性，以及最重要的延迟表现”。从表面看，这是一个典型的成本与性能平衡：用更低成本的模型处理大量请求，同时保持可接受的推理质量。但这里有一个容易被忽略的细节：模型定价不等于单位解决成本。
DevRev 的 Harness 需要检索知识、检查权限、执行工具调用，这些步骤都会产生额外的 token 消耗和系统开销。即使 GPT-6.1 Sol 的单价更低，如果它在复杂任务上需要更多轮次的推理或更高的重试率，最终的单位解决成本未必更低。DevRev 声称 token 数少 4.4 倍，但这一数据来自其自建基准，且未披露是否包含 Harness 自身的开销。对于技术负责人来说，真正需要计算的是“每个成功解决的工单总成本”，而不是“每百万 token 的价格”。
更值得关注的是生态依赖。DevRev 的整个产品栈——从 Computer 和 Operator 的推理到内部开发工具 Codex——都深度绑定了 OpenAI。Ahmed 提到，DevRev 的工程团队在探索多个编码工具后，全员从 Cursor 迁移到了 Codex，并放弃了 Cursor 许可证。销售工程师也用 GPT-6 Astra 创建展台演示。这种全面迁移提高了短期效率，但也意味着 DevRev 的研发流程和产品能力与 OpenAI 的路线图紧密耦合。如果 OpenAI 调整定价、延迟特性或模型退役策略，DevRev 的迁移成本会很高。对于正在评估类似架构的企业，这是一个需要权衡的取舍：垂直整合带来的性能优化，是否值得牺牲供应商的灵活性？
给技术负责人的可操作判断
如果你正在评估或构建企业级自主服务代理，DevRev 的案例提供了几个可操作的判断点。第一，优先投资于 Harness 层，而不是模型选型。模型会迭代、价格会变化，但权限控制、知识检索、可逆操作和来源追溯这些能力是长期资产。DevRev 的架构表明，把模型当作可替换的推理引擎，而把企业上下文和治理逻辑放在自研层，能够降低对单一模型的依赖，尽管 DevRev 自身在生态上并未完全做到这一点。
第二，用你自己的任务分布来验证厂商的基准数字。Enterprise-Bench 的 48% 和 4.4 倍是在特定场景下取得的，你的企业可能有不同的数据版本、权限结构和请求类型。在概念验证阶段，应该设计包含长尾请求、权限冲突和失败恢复的任务集，并测量端到端的解决率和总成本。不要只关注模型在通用基准上的分数，而要关注代理在你的工作流中能否稳定地完成闭环。
第三，把“可逆性”和“可审计性”作为硬性要求。DevRev 强调动作可逆、答案指向来源，这不仅是技术特性，也是风险控制手段。在企业环境中，代理的错误操作可能造成财务或合规损失，因此必须设计回滚机制和操作日志。如果厂商的架构无法提供这些，那么再高的解决率也不足以支撑生产部署。最后，对“自主”保持审慎：DevRev 的下一步是让 Operator 处理更长、更复杂的请求，但公开材料尚未展示其在多步骤、高风险场景下的表现。技术负责人应该从有限自主开始，逐步扩大代理的权限范围，而不是一开始就追求全自动。