办公 Agent 与 Coding Agent

一句话理解：Coding Agent 进步快，不只是因为模型会写代码，而是因为代码世界自带“编译、测试、运行”这类便宜、客观、即时的反馈闭环；办公与业务 Agent 要做强，产品经理必须亲手为它造出类似的反馈闭环。

过去两年，Coding Agent 是公认最先做成的 Agent 形态：Claude Code、Codex 等产品已经能在真实仓库里读代码、改文件、跑测试、提交 PR。而很多办公 Agent——写报告、做分析、处理工单——却常常停留在“看起来不错，但不敢直接用”。

这不是因为办公任务更难理解，而是两个领域的 反馈结构 完全不同。理解这一点，能帮你判断一个业务场景的 Agent 能做到多高的自主性，以及要补什么才能做到。

两个领域的结构性差异

维度	Coding	办公 / 业务
结果能否自动验证	编译、类型检查、单元测试、运行结果	报告“写得好不好”往往只能靠人判断
反馈速度与成本	秒级到分钟级，几乎零成本，可反复运行	常常要等人审阅、等对方回复、等月结
工作环境	仓库、终端、Git：文本化、可复现、可沙箱隔离	分散在邮件、表格、IM、SaaS 与内部系统，权限各异
可回滚性	Git 版本控制，改错了可以撤销	邮件发出、款项付出、客户通知后很难撤回
任务边界	Issue、测试用例、PR 描述相对明确	“整理一份竞品分析”边界模糊，好坏标准因人而异
上下文获取	代码库就在本地，搜索即可	关键知识在人脑、会议和聊天记录里

可以把 Agent Loop 写成：

Coding Agent 每一轮都能拿到 具体、可行动的失败信息，因此可以自己循环十几轮收敛到正确结果；办公 Agent 缺少这个信号，只能一次性交付，然后把验证成本转嫁给人。这也是为什么 Coding 场景可以放心给更高自主性，而办公场景通常停在“草稿 + 人工确认”（参见「自主性等级 L0–L5」）。

反馈闭环的四个来源

一个领域有没有反馈闭环，可以从四个方面看：

1. 客观真值：有没有可以对照的“正确答案”？如测试断言、对账结果、系统状态。
2. 可执行检查：能不能写程序自动检查？如 Schema 校验、规则引擎、读回写入结果。
3. 低成本试错：能不能在不影响现实世界的地方先试？如沙箱、测试环境、草稿、预演。
4. 可回滚：做错了能不能撤销？如版本控制、软删除、延迟执行。

Coding 四项俱全；多数办公场景四项都弱。但业务 Agent 往往比“写报告”这类纯办公任务幸运——因为业务系统里有大量 状态与规则，可以被改造成反馈信号。

为业务 Agent 造反馈闭环：订单售后案例

「订单售后处理 Agent」本身属于业务 Agent，我们可以逐项为它补齐反馈闭环：

反馈来源	Coding 中的对应物	订单售后 Agent 的设计
客观真值	测试断言	退款引擎的卡点码、退货质检的结果字段、类目退款条款——结论必须能落到这些字段上
可执行检查	编译 / Lint	输出契约校验：cause_type 必须是枚举值，每条结论必须引用至少一条证据记录 ID
结果验证	跑测试看是否通过	执行“优惠分摊重算”后，重新调用 list_promo_allocations 读回，确认已挂到正确子订单；再调用 get_refund_blocks 确认卡点是否解除
低成本试错	本地分支	写入动作先调用 dry_run 接口，返回将要变更的字段与影响金额
可回滚	Git revert	分摊重算保留原值，支持一键撤销；资金类动作走审批与延迟执行
离线回归	CI 测试集	100 张历史工单作为评测集，每次改 Prompt、Skill 或工具后重跑

这样一来，订单售后 Agent 的循环就从“猜一个原因交给人”变成了：

反馈闭环一旦建起来，Agent 就能像 Coding Agent 一样 自己发现自己错了，自主性才有资格往上调。具体验证手段参见「各类动作的验证方式」。

纯办公任务怎么办

对于报告、方案、邮件这类没有客观真值的产出，可以用下面几种“弱反馈”组合逼近：

• 结构化契约：先约定大纲、必须覆盖的问题、每个结论必须引用数据来源，再让程序检查是否满足。
• 可追溯证据：每个数字都链接到查询结果，人审阅时只需抽查证据（参见「证据与可解释」）。
• 评分器组合：用 LLM-as-Judge 按明确 Rubric 打分，并定期用人工评分校准（参见「评分方式」）。
• 以产物为中心的迭代：把结果做成可编辑的文档或表格，而不是一段聊天回复，让人的修改本身成为反馈数据。
• 缩小 Job：把“写一份竞品分析”拆成“抓取 5 家竞品定价页并填入固定表格”，后者就有了可检查的结构。

这对产品决策意味着什么

1. 优先选择有反馈闭环的 Job。 同等价值下，结果可验证的场景更容易做到高成功率与高自主性。
2. 把“补反馈闭环”列进路线图。 读回接口、dry-run 接口、评测集、可回滚机制，往往比换更强的模型更能提升效果。
3. 自主性与验证能力挂钩。 没有验证手段的动作，不要给自动执行权限。
4. 向 Coding Agent 学习 Harness 设计。 沙箱、权限模式、计划模式、检查点这些机制，大多可以迁移到业务 Agent（参见「Claude Code 拆解」）。

常见误区

• “Coding Agent 强是因为模型编程能力强。” 模型能力是一部分，但测试、终端、Git 构成的反馈环境同样关键。把同一个模型放进没有测试的仓库，效果会明显下降。
• “办公场景就只能做 Copilot。” 如果能把结果落到系统状态与规则上，业务 Agent 同样可以获得客观反馈并提高自主性。
• “让模型自己检查一遍就算验证。” 模型自评容易与原答案犯同样的错。优先使用程序化、外部的验证（参见「自我检查与外部验证」）。

产品经理检查清单

• 这个 Job 的结果有没有客观真值？落在哪个系统、哪个字段上？
• 每一个写入动作之后，Agent 能否读回确认？
• 有没有 dry-run、草稿或测试环境可以低成本试错？
• 做错了能不能撤销？撤销窗口多长？
• 有没有一套可以每次改动后重跑的历史案例评测集？
• 没有客观真值的产出，是否用结构化契约和证据引用降低了审阅成本？

练习

选两个你熟悉的 Agent 场景（例如“修复一个失败的单元测试”与“写一份周销售分析”），花 30 分钟：

1. 按“客观真值、可执行检查、低成本试错、可回滚”四项分别打 0–2 分。
2. 为得分低的场景设计至少三个补反馈闭环的措施。
3. 根据得分，判断两个场景第一版分别适合什么自主性等级。

下一步

现在你已经有了 Job、流程、步骤归类和反馈闭环设计。下一课「Agent PRD」会把它们整合进一份 20 项的完整 PRD。