Claude Code 产品设计（五）：Agent 产品真正设计的是责任，而不只是操作

Claude Code 产品设计系列：1 · 产品地图 · 2 · 任务体验 · 3 · 信任与验证 · 4 · 会话与协作 · 5 · 深入思考

阅读时间为估计，包含图表理解；动手实验另计。

范围：基于 2026-09-05 可访问的 Claude Code 官方文档做产品设计分析。CLI、Desktop、Web 的能力不完全相同；下文会区分已有机制、教学抽象与作者建议，不把界面草图当作官方截图。

前四篇分别回答了如何开始任务、怎样授权、如何验证、怎样协作。但把这些功能全部装进产品，不一定能减少人的工作。

如果用户要为每个任务整理大量上下文、解释权限、核对日志、解决并行冲突，那么自动执行节省的时间可能被监督成本吃掉。最终应衡量的，不是 Agent 做了多少动作，而是人以多低的负担获得了多少合格结果。

把前文重新收束成一张责任表

责任	默认承担者	产品必须提供的证据或控制
定义目标与禁止项	用户与组织	清楚的任务契约与可调整范围
选择执行路径	Agent	可追踪的调用、进度和异常
限制影响面	平台与运行环境	权限、隔离、凭据与停止机制
判断交付正确	独立检查与人	测试、Diff、业务验收与争议处理
决定是否发布	有权的责任人	明确发布对象与剩余风险

“模型负责路径，人负责意图”是一种职责安排，不意味着 Agent 的输出可以替人承担事故后果，也不意味着每一个低风险任务都必须手工验收。

产品设计上的四个长期挑战

功能发现与概念负担

Local、Remote、SSH、权限模式、Skills、Hooks、MCP、Plugins、Subagents、Teams 和 Routines 对高级用户很强，但新用户难以一次理解。产品需要围绕任务推荐下一项能力，而不是要求用户先学习完整术语表。

可观察性与信息过载

过程太少，用户无法建立信任；日志太多，关键状态会被淹没。好的默认界面应优先展示“当前目标、正在做什么、为什么停住、验证证据、下一次需要人做的决定”，其余细节按需展开。

能力碎片化

套餐、模型、操作系统、推理供应商与企业策略可能让 Auto、Remote、Computer Use 或导入导出不可用。页面应解释能力缺失的原因与恢复路径，避免用户把策略限制误认为产品故障。

工程完成不等于业务正确

测试通过和 CI 绿色是强证据，却不能证明需求方向正确。下一阶段的 Agent 产品需要把产品验收标准、用户反馈、线上指标与回滚条件接入同一验证闭环。

一个容易被忽略的变量：证据债务

任务做得越快，未被理解的变更也可能堆得越快。测试绿色、Diff 很大、说明很长，仍可能没有人能解释关键行为。

可以把这种状态称为“证据债务”：系统生成了结果，却没有生成足够容易理解、能支撑决策的证据。这是本文提出的分析概念，不是官方指标。

治理它的办法不是让模型写更长的总结，而是缩小变更单元、保留独立验收、让关键风险可以定位，并限制超过团队审查能力的并行任务数。

怎样验证这些设计真的有用

假设	应同时记录	可能的反例
渐进披露降低学习成本	首任务成功、错误环境选择、求助次数	关键能力被藏得找不到
自动授权降低打断	确认次数、误放、误拦、接管时间	少弹窗却多返工
并行提高交付效率	合格变更、人类审查时间、冲突	生成加速，审查队列堵塞
长期上下文减少重复解释	准确引用、过期规则、纠错成本	旧经验持续误导新任务

这些是作者建议的验证维度。原文中的使用研究百分比不再作为设计有效性的因果证明；用户使用更多、厂商内部产出增加，都不能单独证明某个 UI 机制造成收益。

反例：什么时候应该少一点 Agent

目标很模糊、结果很难验收时，让 Agent 高速实现可能更快固化错误方向。任务高度耦合、共享状态很多时，增加子任务数可能只会放大协调成本。授权和数据边界尚不清楚时，扩展工具集可能先扩大风险。

此时最好的产品动作可能是澄清、缩小范围、减少并发，或者保留人工处理，而不是继续增加自动化选项。

最终判断：优秀产品让责任更清楚，而不是更隐形

任务型入口给意图一个位置，证据界面让完成可以核对，权限与隔离限制影响，会话让工作能持续。它们最后服务于同一个目标：让用户知道什么时候可以交出去，什么时候应该介入，什么时候必须停止。

如果读完系列只记住一条，可以是：Agent 产品的成熟度，体现在它如何处理未完成、未知和不被允许，而不只体现在成功演示。

这也是为什么所有局部设计最终都应回到“责任分配”——自动化可以移动操作，却不能让风险与判断凭空消失。

---

上一篇：会话与协作。

本系列到此完成。工程机制可继续对照 Anthropic Harness 建设；产品价值的验收口径见 AI 产品价值系列。