Agent 时代 SaaS 设计

经济学：BYOA（用户自带 agent/token）拯救利润率

• 用户在自己的 agent 里用你的产品时，烧的是用户自己的 token，不是你的。于是你不必抢着往产品里塞一个自建 agent 并为推理成本买单——转而做"人和 AI 都愿意在上面协作的软件"。
• Every 全员用 agent，SaaS 支出反而逐年上升；agent 作为新增"用户"会带来需求暴涨（GitHub 当前的负载问题就是 agent 流量指数增长所致）。附带产生基础设施和定价的新挑战。

设计范式：从"人用"或"agent 独立用（CLI）"走向"人 + agent 同一件工作上协作"，要点：

1. 产品可以更简单：格式化、排版、做表格这类功能不用做了——agent 替用户做（Proof 没做 Word 式格式化）；比 legacy 产品更快起步。
2. 双向可见性与同步：agent 用 CLI、人用 Web 界面，两者必须实时同步；CLI 里发生的任何事要立刻反映给人。
3. 应对 agent 的操作规模：agent 可以三秒内做一亿个请求、一次改一万处。需要：审批机制、汇总式 inbox（"将要/已经发生了什么"）、日志、一键快速回滚。
4. agent-to-agent onboarding：假设用户带着 Codex/Cowork 来，onboarding 从"填写引导表单"变成"往 agent 里贴一个 prompt"——用户的 agent 会与你的应用（普通 server 或你方 agent）对话，主动提供关于用户的丰富上下文（"Dan 最近在做这些事、可能想这样用"），生成高度定制的体验。两个 agent 互聊优于一个 agent："two agents are better than one"。
5. agent 提交的 bug report 优于人类：精确复现步骤 + （开源项目还能带）代码层面的猜测，直接变 GitHub issue，再派一个 agent 去修——形成"用户碰到 paper cut → 用户 agent 找公司 agent → 修复"的极快闭环。出问题时用户也可以直接叫自己的 agent 去和你的应用对话排查（"Codex, go fix it"）。

规模效应实例：OpenClaw 维护者每天收几千个 PR，用 5 万个 Codex 实例分拣、合并上千个。产能加到流程一处，压力挤向另一处——"能不能建出来"不再是问题，问题变成"它与整体是否协调、该删掉什么"（Anthropic 大量删 Claude Code 功能防臃肿是正面示范）。