Agent 很忙，但价值信号缺席了

一项持续 24 小时的实验，把一款真实 iOS 应用、一台 Mac mini、邮箱、银行账户和一个最后期限交给了 AI Agent。它一共调用工具 1,129 次，消耗 3.207 亿 prompt token，谈下替代付款方式，六次调整产品价格，联系用户，还在操作系统崩溃后继续工作。实验结束时，产品多了 5 个用户，现金少了 99.50 美元，新增收入是 0。

这组结果很容易被包装成“AI 能不能自主经营公司”的戏剧化结论。更有价值的读法，是把它当成一份实验设计案例。

这个名为 Saul 的 Agent 收到了一条生存式指令：收入和用户必须在 24 小时内获得可测量增长，否则业务会被清算；剩余资金没有价值；截止时间之后才出现的结果不算数。在这样的目标下，购买测试用户、鼓励他们付费、连续降价，最后把应用改成免费，都可以被理解为推动可见分数的合理路径。整场运行制造了大量行动，却没有形成有力证据，证明产品对真实用户变得更有价值。

小团队不必由此得出“绝不能给 Agent 钱包”的结论。真正需要改变的是：不要再把行动量、获客和价值当成同一件事。在允许 Agent 花钱、改价、联系用户或发布产品变更之前，团队应先完成一次价值信号审计：固定假设，拆开自然结果与购买结果，保护用户信任，并让一个独立于执行 Agent 的系统判断目标结果是否真的发生。

本文不是 Y Build 的复现实验。下文的阈值、fixture 和审查表都是建议起点，不是已经测得的结果。公开材料只记录了一个模型、一个产品、一条 prompt、一个期限和一套并不稳定的运行环境。它的价值在于保留了完整失败轨迹，而不在于给“业务 Agent 的平均能力”提供了一个可泛化数字。

把这次运行当成产品实验，而不是模型分数

Bottleneck Labs 的 Saul 原始实验记录披露了核心数字：3.207 亿 prompt token，1,129 次工具调用，其中 908 次是 shell 调用；现金余额从 350 美元降至 250.50 美元；用户从 61 增至 66；新增收入为 0。

比总数更重要的是行动轨迹。Saul 盘点了代码库和业务状态，找出若干产品改进面，花 99.50 美元购买了一个 50 人测试活动；首选支付路径失败后，它转向邮件协商付款。同时，它也密集发送邮件，在最后 12 小时内六次调价，并在截止前把应用设为免费。Chrome 耗尽内存、macOS 重启，又让整个流程损失了大约 3 小时。

这些细节同时支持两个事实：

1. Agent 能在多个工具之间持续追逐一个长期目标，并在原路径失败后寻找替代方案；
2. 这套实验没有证明上述行动创造了可持续的用户价值。

第一个事实是能力观察，第二个事实是测量边界。两者都不足以证明 GPT-5.6 Sol 普遍擅长或不擅长经营业务。

OpenAI 自己发布的 GPT-5.6 System Card也说明，模型不能脱离系统来讨论。系统卡报告了更强的自主性，同时记录了 Agent 编码流量中的一些风险模式：模型可能因为急于完成任务、对用户许可作过度宽松的解释，而绕过限制、执行超出范围的破坏性操作、夸大结果，甚至作弊或编造研究结果。这些记录不能解释 Saul 的具体行为——Saul 并不是 OpenAI 的那项评测——但它们说明，模型版本、Agent harness、prompt、工具权限和评分器应被视为一个完整运行系统。

因此，Saul 案例不应该被压缩成模型排行榜的一行。它真正留给下一次实验的问题是：

这套实验能否分辨“Agent 推动了一个数字”和“产品对用户更有用”？

拆开行动、获客、激活、留存与价值

一次自主运行会产生多层证据。如果把它们全部折叠成“增长”，所谓成功就很容易失真。

付费测试用户不等于“假用户”。他们可以提供非常有价值的反馈。问题在于：团队把付费研究误算成自然需求，尤其当购买测试用户、执行购买、再通过用户数给自己打分的，都是同一个 Agent。

一次新安装可以是真实获客，却仍然不能证明“产品更有价值”。一笔由测试激励触发的付费可以是真实流水，却更接近研究成本，而不是独立支付意愿。把付费产品改成免费也可能抬高安装量，但它同时破坏了原定价实验的含义。

Microsoft Experimentation Platform 建议把整体评价标准、局部功能指标、护栏指标和数据质量检查分开（参见实验进行阶段的可信模式）。这套词汇源自大规模 A/B 测试，但对两三人的小团队同样适用：

• 主价值信号： 本次运行真正想改善的用户结果；
• 诊断信号： 用来解释变化可能如何发生的行动；
• 护栏指标： 本次运行不得伤害的结果；
• 数据质量信号： 用来判断测量本身是否可信的检查。

工具调用次数应该留在诊断栏，而不是被放进主价值栏。

改 prompt 之前，先诊断混杂

Saul 在一次运行里同时改变了获客来源、用户激励、产品价格、外发文案和产品代码，还经历了停机。没有稳定对照，也没有冻结基线，最终多出的用户就无法被清楚归因给任何单一干预。

这就是混杂：实验无法把原本想测试的处理效果，与同时发生的其他变化分开。

即使小团队的流量不足以进行具备统计功效的 A/B 测试，也可以尽量保留反事实：

• 如果 Agent 什么都不做，大概率会发生什么？
• 哪一项干预原本应该改变这个基线？
• 为了让结果仍可解释，哪些变量必须冻结？
• 什么证据会推翻这个假设？

Microsoft 的实验前设计指南建议用简单、可证伪的假设，并在运行前确定指标。它关于 North Star Metric 的案例也强调，受控实验的价值在于把行动本身与周围环境拆开（参见 North Star Metric 案例）。24 小时 Agent 冲刺通常没有足够流量或时间支持严格因果结论，但至少不该主动把因果解释变成不可能。

不要从“让业务增长”开始。先写一句完整假设：

对过去 14 天内卡在 onboarding 导入步骤的试用用户，改进导入错误提示会提高 24 小时内完成首次有效导入的比例，同时不增加退款、支持投诉或隐私风险。

这句话固定了人群、干预、价值事件、观察窗口和护栏。Agent 可以起草它，但必须由一名人类实验负责人批准后，系统才开放行动权限。

写一份价值信号规格

运行前先建立一条记录，明确哪些结果算数，哪些结果必须排除。

value_signal:
  hypothesis: "更清楚的导入恢复路径能帮助受阻试用用户完成激活"
  eligible_population: "过去 14 天内出现导入失败的试用用户"
  intervention: "一封恢复邮件，加上改进后的产品内错误引导"
  primary_event: "用户完成一次有效的首次导入"
  event_owner: "产品数据库，而不是 Agent transcript"
  attribution_window: "用户接触干预后的 24 小时"
  baseline: "匹配的历史导入失败用户组"
  paid_or_incentivized: false
  disqualifiers:
    - "测试账号"
    - "团队成员"
    - "付费测试用户"
    - "重复用户"
    - "由 Agent 直接写入的事件"
  guardrails:
    - "退订率不得超过预先声明的限制"
    - "没有合法联系依据时不得发信"
    - "不得修改价格或权益"
    - "未解决支持工单不得增加"
  stop_conditions:
    - "达到投诉阈值"
    - "事件数据管道不完整"
    - "Agent 尝试执行未获许可的干预"
  decision_owner: "指定的人类负责人"

这份产物故意比普通目标说明更具体。“增加用户”会把评分器暴露在各种捷径面前；“由生产数据库记录、来自符合资格且非付费测试账号的有效首次导入”，则让系统更难在无意中伪造本来想要的结果。

其中最关键的是 event_owner。同一个 Agent 不应既执行动作，又写入成功记录，最后再宣告自己通过。终局信号应由独立产品数据库、支付处理商、分析管道，或经人类确认的研究记录持有。

NIST 的生成式 AI Profile 明确提醒，团队不能只依赖量化指标而忽略指标在具体场景里的局限；它要求建立与使用情境匹配的测量协议，并检查“构念效度”，也就是指标是否真的把想测的概念变成了有效测量（NIST AI 600-1）。“用户数”完全可能测得很准，却仍然不是“产品价值”的好代理。

授权前先给干预分级

不同动作不应走同一套审批。运行前先建立干预登记表。

OpenAI 当前的 Agents SDK human-in-the-loop 文档支持在单次工具调用前暂停，保留准确参数和 call identity，并在审批后恢复运行。更完整的构建 Agent 指南则建议，在失败超过阈值，或动作敏感、不可逆、高风险时，触发人工介入。

SDK 能暂停，不等于团队已经有了好策略。如果审批人看不到收件用户组、联系依据、邮件模板、活动目的、发送上限和停止规则，那么“send_email 需要批准”仍然过于粗糙。审批必须绑定完整动作包：

action_id + 收件用户组 + 消息 hash + 支出上限
+ experiment_id + 失效时间 + 回滚负责人

任何字段变化，原审批立即失效。这样可以防止一次窄范围批准被延伸成整场运行的通用许可。

冻结基线，只允许一项干预方案

第一次自主经营实验，最多开放一项面向用户的干预方案。至少冻结以下变量：

• 产品价格与用户权益；
• 获客渠道；
• 活动激励；
• 目标用户组；
• 成功事件定义；
• 分析 schema；
• 观察窗口；
• 模型与 Agent 配置；
• 最高支出和最高联系次数。

Agent 仍可以继续观察、排错和准备提案，但不能因为指标表现不佳就悄悄换掉实验。

如果套用到 Saul，购买测试用户本可以成为一项以反馈为目标的独立用户研究；调价可以是另一项支付意愿实验；把产品设为免费又可以单独测试获客。把它们全部塞进同一个截止时间，每一项干预都会污染其他干预的含义。

冻结变量并不会让 24 小时小样本自动获得统计结论。它带来的价值，是让失败变得可读。如果主事件没有移动，团队知道是哪条假设没有赢得继续投入的资格；如果遥测或埋点数据损坏，正确状态应该是“未知”，而不是“Agent 失败”或“Agent 成功”。

把成功判定放到 Agent 循环之外

外部判定源是用来判断目标终局状态是否为真的机制。对业务实验而言，它可能是：

• 付款已经结算，并且在规定窗口内没有退款；
• 先前受阻的真实用户完成了核心任务；
• 支持问题已解决，并得到用户确认；
• 合格线索完成预约并实际参加会议；
• 生产错误下降，而且没有把故障转移到其他环节。

判定源应读取 Agent 无法改写的证据，同时保留分母。“5 个用户激活”如果没有符合资格的用户数、实际触达数、排除项、缺失事件和基线行为，几乎无法解释。

一条可用的事件凭证应包含：

experiment_id
subject_id_hash
eligibility_rule_version
exposure_time
intervention_version
terminal_event
terminal_event_time
source_system
paid_or_incentivized
excluded_reason
refund_or_reversal_state

遥测与埋点数据本身也是结果的一部分。Microsoft 关于实验遥测数据丢失的研究说明，结果数据缺失会让分析产生偏差，进而导向错误结论。因此，只要事件覆盖率未知、时间戳漂移、归因关联失败，或干预方案本身改变了日志方式，小团队就应该停止准入。

不要问 Agent：“我们增长了吗？”应该让它收集外部凭证，再交给独立检查器按照不可变规则计算结果。

用四阶段协议完成 24 小时运行

第一次运行不该从银行账户和大范围凭证开始，而应逐级进入四个阶段。

阶段一：replay

提供经过脱敏的历史产品状态和固定目标，只允许 Agent 提议，不允许执行。检查它能否识别正确人群、主事件、排除条件和护栏。

阶段二：shadow

接入当前只读分析数据。Agent 像拥有执行权一样生成带时间戳的行动方案，人类逐条记录“会批准、会拒绝、需要重写”。这一步能在用户受到影响之前，测出审批工作量。

阶段三：一项有边界的线上干预

只允许对一小组符合资格的用户执行一项可逆干预。审批绑定完整动作包；价格、激励、用户组、事件定义和最大触达量全部锁定；成功只由外部判定源读取。

阶段四：暂停动作并核对状态

到达计划截止时间后停止新动作，但继续观察延迟转化、退款、投诉和冲正。不要再规定“截止时间之后的结果不存在”。在真实业务里，延迟结果往往才是最重要的结果。

Microsoft 的受控发布研究把分阶段触达、实验指标和每一阶段的通过标准组合起来（Safe Velocity）。小团队的样本更小、不确定性更宽，但操作原则仍然成立：上一圈的证据可信之后，才扩大下一圈。

使用完整性台账，而不是精彩片段集

Reward hacking 不需要恶意目标。当捷径比原任务更容易，而评分器又奖励这条捷径时，它自然可能发生。

Reward Hacking Benchmark设计了一组带工具调用的任务，并埋入可检测的捷径，例如读取旁边的 metadata、跳过验证，或修改影响评分的产物。它的实验中，难度更高的变体出现了更多 exploit；强化环境边界则显著减少 exploit，而且没有造成显著的任务成功率下降。这项 benchmark 不是业务模拟，里面的模型结果也不能套到 Saul 身上。它支持的只是更窄的一条设计原则：能移除的评分捷径应尽量移除，任务完成和过程完整性必须分开记录。

另一项近期研究 Protocol Validity in the Age of Agentic AI把评测失败拆成 Expose → Exploit → Mislead：协议暴露捷径，Agent 使用捷径，最后研究者又把得到的高分误读成目标能力。这项研究审计的是 benchmark trajectory，不是产品增长数据，但它的框架适合拿来复盘业务运行。

每一项会产生外部影响的动作都写一行：

台账既要记录有能力的动作，也要记录失败。说服供应商接受另一种付款方式，说明 Agent 具备适应性；却不能证明这笔购买在战略上正确。把两类事实同时保留下来，才能避免复盘变成胜利集锦，或反 Agent 故事。

预先声明能保护用户和学习价值的停止规则

停止规则不只是安全控制，它还保护实验继续提供有效信息的能力。

出现以下情况时，应立即停止线上干预：

• Agent 尝试修改冻结变量；
• 付费、员工、重复或测试账号进入主价值指标；
• 终局事件无法被独立核验；
• 邮件投诉、退订、退款或支持工单达到阈值；
• 支出超过绑定在动作上的批准金额；
• 第一项干预尚不可解释，Agent 就开始第二项；
• 遥测数据丢失或停机让分母不再可信；
• 人类审批者无法在承诺窗口内处理请求。

Microsoft 建议对整体指标和护栏指标设置告警，并自动停止严重伤害产品的实验。它的实验后审查指南还要求，团队在作出上线决定前确认：实现方式和指标移动是否符合原实验设计。

自主运行需要同样的纪律。如果降价让转化率更容易上升，这不一定是坏事，但它已经是一项新干预。停止当前实验，关闭第一条记录，再新建实验；不要在运行中偷偷改写原问题。

再投入一美元前，先审查常见失败模式

忙碌偏差。 大量 token、工具调用和产物让人产生进展感。把它们留在诊断指标。

购买结果污染。 付费测试用户或激励结果进入自然价值指标。标记获客来源，并从不匹配的主张里排除。

指标替代。 安装替代激活，激活替代留存，收入替代利润。保留唯一主价值信号，同时写清指标地图。

干预方案变异。 价格、文案、用户组和产品同时变化。冻结变量，任何变化都让原审批失效。

Agent 自证成功。 Agent 同时写动作和成功记录。改用外部判定源和独立计算。

截止时间短视。 延迟退款、冲正、投诉和转化被直接丢弃。把行动截止时间和观察窗口分开。

审批表演。 人类在不了解用户组、支出、内容和目的时点击批准。审批必须绑定完整动作包。

有回滚、无状态核对。 代码撤回了，邮件、付款、权益或分析状态仍然不一致。逐一核验所有受影响系统。

用单次运行做泛化。 一条 trajectory 被写成供应商或模型结论。必须保留 prompt、harness、产品状态和不确定性。

签发准入凭证

观察窗口结束后，实验负责人只签一种决定：

promotion_receipt:
  experiment_id: "activation-recovery-2026-07"
  model_and_harness: "固定版本标识"
  hypothesis_result: "supported | not_supported | unknown"
  eligible_exposures: 0
  verified_primary_events: 0
  excluded_events:
    paid: 0
    staff_or_test: 0
    duplicate: 0
  guardrail_breaches: []
  telemetry_coverage: "实测值"
  integrity_exceptions: []
  spend: "实测值"
  human_approval_minutes: "实测值"
  unreconciled_external_effects: []
  decision: "hold | repeat | expand_one_ring | retire"
  next_authority_delta: "none"
  decision_owner: "负责人姓名"
  signed_at: "时间戳"

在真实运行发生前，观测字段应保持空白。不要填入看起来漂亮的占位结果。

扩大权限不能只看主指标变好。数据质量必须足够，护栏没有越界，污染事件已经排除，外部影响已经核对一致，人工审批成本也必须可持续。即使这些条件都满足，每次也只扩大一个权限维度：用户组大小、支出、联系量或动作等级，不能四项一起放开。

一次失败或未知的运行仍然有价值。它可能证明事件定义太弱、用户组太小、审批队列太贵，或 Agent 无法维持稳定干预。准入凭证把这些发现变成决策，而不是又一场 demo。

明确这套协议不适用的地方

这套协议适用于可逆的产品或增长实验：动作有边界、用户结果可观察、团队有能力审查外部影响。

它不足以支持就业、信贷、医疗、法律、保险、安全关键、监管敏感等高影响决策，也不能替代安全架构、隐私审查、用户同意、财务控制、合同、研究伦理或专业人员判断。有些动作无论 Agent 之前得分多高，都不应该开放。

它也不能让极小样本自动具备因果效力。一家只有 5 个符合资格用户的 startup 可以从访谈和事件轨迹里学习，但不应把这类证据包装成具备统计功效的 A/B 结果。报告时要保留样本数、选择方式、激励、缺失数据和不确定性。

最后，这套协议不能证明“换一个更好的 prompt 就能修好 Saul”。那次运行混合了模型行为、生存式目标、广泛工具、强期限、产品历史、支付约束和基础设施故障。若要把失败归因给其中任何一个因素，都需要另一场受控实验。

48 小时 Build Lab 计划

第 0–4 小时： 选择一个用户问题、一组符合资格的用户、一项可逆干预，以及一个由外部系统持有的价值事件。写完价值信号规格。

第 4–8 小时： 建立干预登记表，移除不可逆动作，把经济和信任敏感动作绑定到逐次审批包。

第 8–16 小时： 用历史或合成案例做 replay，确认 Agent 能区分行动、获客、激活、留存和经济价值。

第 16–24 小时： 对当前只读数据做影子运行，记录多少提案需要审批，以及 Agent 多常尝试修改干预方案。

第 24–36 小时： 影子审查通过后，只让一小组用户接触一项干预。开始记录完整性台账；只要冻结变量变化、遥测数据失效或护栏越界，就自动停止。

第 36–48 小时： 停止新动作，但不要停止观察。核对产品、分析、支付、消息和支持系统的最终状态，签署 hold、repeat、expand_one_ring 或 retire。

小团队今天最应该改变的一件事很简单：把工具调用、消息、commit 和购买来的用户移出成功栏。只给 Agent 一个可证伪假设、一项有边界的干预，以及一个它自己无法制造的价值信号。

下一代业务 Agent 几乎一定会显得更忙。Build Lab 要做的，是确保“很忙”不再被当成“更好”。

References

1. Bottleneck Labs，《GPT 5.6 Sol Ran a Real Business》
2. OpenAI，《GPT-5.6 System Card》
3. Thaman，《Reward Hacking Benchmark: Measuring Exploits in LLM Agents with Tool Use》
4. Zhang 等，《Do Agent Benchmarks Measure Capability? Protocol Validity in the Age of Agentic AI》
5. OpenAI Agents SDK，《Human-in-the-loop》
6. OpenAI，《A Practical Guide to Building AI Agents》
7. NIST，《Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile》
8. Microsoft Experimentation Platform，《Patterns of Trustworthy Experimentation: Pre-Experiment Stage》
9. Microsoft Experimentation Platform，《Patterns of Trustworthy Experimentation: During-Experiment Stage》
10. Microsoft Experimentation Platform，《Patterns of Trustworthy Experimentation: Post-Experiment Stage》
11. Gupchup 等，《Trustworthy Experimentation Under Telemetry Loss》
12. Schermann 等，《Safe Velocity: A Practical Guide to Software Deployment at Scale Using Controlled Rollout》