Agent执行责任表：权限预设、审批设计与轨迹记录

DeepSeek Harness 的发布让 Agent 从回答问题走向真实操作，但产品经理真正该关注的是：用户如何知道 Agent 做了什么、为何能做、出问题谁负责？本文拆解 Harness 的执行链路、权限预设与审批设计，为 Agent 产品的责任边界与交互体验提供清晰思路。

DeepSeek Harness 发布后，最容易写成一篇开发者说明。安装命令、代码目录、插件接口和四种运行模式都很新，也都离人人都是产品经理的主要读者有些远。

我把官方页面、架构文档、会话记录、工具执行、权限预设和沙箱说明重新对了一遍，又查了站内关于 Agent 工具和 Harness 的文章。对产品经理更有用的问题集中在一件事上。

当 Agent 从回答问题走到修改文件、运行命令和调用外部工具，产品要怎样让用户知道它做了什么，为什么可以做，出了问题又该由谁处理。

DeepSeek 在官网用了一个很短的表达。Agent 由模型和 Harness 共同构成。模型负责判断下一步，Harness 负责理解环境、使用工具并让任务在真实工作区里继续。

这个区分让一张常被省略的产品图重新变得重要。它记录一次操作从提出到完成的全过程，也标出用户、模型、工具和运行环境各自承担的责任。

一句任务怎样变成一次真实动作

假设用户给 Agent 一项常见任务，让它修复项目中的一个登录问题。

聊天框里只有一句话。执行层需要做的事情多得多。Agent 要找到相关文件，读取项目规则，决定修改位置，再运行测试检查结果。工具可能访问工作区之外的目录，也可能启动进程或请求网络。中途任何一步失败，后面的判断都会受影响。

模型生成一个工具调用，只代表它提出了动作。Harness 接收请求并交给对应工具以后，文件才会被读取，命令也会开始运行。工具返回结果以后，Harness 还要把结果放回会话，让模型决定下一步。

产品界面如果只展示用户问题和最后答案，中间发生的事情就会被压缩成一句“任务已完成”。用户无法判断 Agent 是否读错了项目，是否执行了超出任务范围的命令，也无法知道最后的结论有没有经过测试。

DeepSeek Harness 的价值之一，是把这段执行过程作为可观察对象。官方说明提到，模型看到的系统提示、工具调用及结果、子任务调度和上下文注入都会进入追加式会话记录。用户可以在 Trajectory 视图中查看，并基于同一条事件流继续、分叉、搜索或重放。

对产品经理而言，这比再增加一个模型选项更接近日常工作。用户会追问 Agent 是否执行过动作，任务做到了哪里，结果还能不能核对。

把这条任务再走细一些，责任空白会更明显。

Agent 收到登录问题以后，第一步通常是理解项目。它会读取目录、搜索相关代码和测试，再选择可能需要修改的文件。读取动作风险较低，也可能碰到工作区中的密钥、配置和与当前任务无关的资料。产品若只在首次选择工作区时问一次“是否允许访问”，用户很难知道后面的搜索范围。

Agent 找到文件以后准备修改。一次修改可能只影响一行判断，也可能顺带调整依赖和配置。界面若只显示“编辑文件”，用户仍然不知道改动大小。更有用的信息包括目标文件、预计影响和修改后的差异。用户无需逐字审查每次小改，至少应该知道 Agent 正在越过哪个边界。

接下来是运行测试。命令会启动进程，可能读取环境变量，也可能下载依赖或访问外部服务。测试失败以后，Agent 可能继续修改，也可能请求扩大权限。每次重试都在改变任务状态。最终答案只写“测试通过”，无法解释它先失败了几次，哪些失败来自代码，哪些来自环境。

这条过程里有几种不同的决定。模型选择下一步，策略判断动作是否符合规则。需要人工同意的例外再交给用户。它们混在一个“思考中”状态里，出了问题就没人说得清。

产品可以把它们分别显示。模型建议修改某个文件，属于任务计划。策略拦住工作区外写入，属于系统限制。用户批准一次更高权限的重试，属于明确授权。这样记录下来，团队才能在事后判断哪种决定需要调整。

工具和执行环境也需要分开理解。文件编辑工具可以提交一个写入请求，实际能否写入由文件系统能力和沙箱决定。终端工具可以发起命令，进程是否被限制在指定工作区，又取决于执行后端。产品把工具名称展示出来，只完成了一半说明。

用户关心动作落在哪里。读取和搜索影响信息范围，写入会改变工作区状态。进程执行还可能连接网络或启动后台任务。相同工具在不同权限模式下，后果可以完全不同。责任表因此要同时记录工具、当次权限和实际结果。

DeepSeek Harness 的官方文档强调，每次执行都携带自己的策略。工作区根目录来自会话开始时确定的位置，单次获批的更高权限只覆盖那一次调用。这种设计避免一个例外自动扩大后续全部动作，也给产品界面提供了清楚的表达方式。

用户批准的应该是一项具体动作。它在什么目录运行，需要扩大到哪种范围，为什么原权限不足，执行结束后权限是否恢复，这些内容都可以放在同一个确认中。审批由此落到当次后果，不再只是一个笼统开关。

审批按钮应该提供足够信息

Agent 执行敏感动作时，常见做法是弹出一个审批框。只有“允许”和“拒绝”两个按钮，审批仍然很难完成。

用户需要在点击前看懂动作内容和影响范围。准备修改哪个文件，命令会在什么目录运行，是否可能访问网络，失败后是否留下中间状态，这些信息决定了用户能否承担批准后的结果。

权限也不能只分成“可用”和“不可用”。读取文件、写入文件、启动进程和访问网络面对的风险不同。一个适合个人试验的默认设置，放进企业代码库后可能过于宽松。一个完全只读的环境很安全，也可能让任务始终停在建议阶段。

DeepSeek Harness 把工具执行、策略检查与沙箱放在不同位置处理。这个结构给产品设计一个明确提醒。审批负责让人作决定，策略负责拦截不符合规则的请求，沙箱负责限制动作实际能够影响的范围。三个环节可以配合，无法互相替代。

有些团队把所有风险都压到审批框里，结果是用户在任务过程中反复确认。点击次数越来越多，人会逐渐形成无条件放行的习惯。审批失去判断价值后，界面仍然显示“经过用户同意”，实际控制已经很弱。

更稳妥的做法，是先按任务建立默认范围。日常代码检查可以读取指定工作区，修改操作限制在明确目录，网络访问和工作区外写入单独确认。用户看到的审批数量会下降，每一次出现也更容易理解。

DeepSeek Harness 当前提供的权限预设能说明这种设计怎样落到产品上。官方文档列出的默认组合包括 workspace-write 和 danger-full-access。前者把文件影响限制在工作区，并在需要时询问用户。后者允许更大的访问范围，同时可以配置成不再逐次询问。

两个名称很短，背后包含两项独立设置。沙箱模式决定动作能影响哪里，审批策略决定何时询问。权限预设只负责把它们组合成用户可选择的名称，执行限制仍由沙箱和审批机制承担。

如果用户选择 workspace-write，产品不能只显示一个绿色的“安全”标签。这个模式主要限制文件影响范围，不自动代表网络、凭据和外部插件都处于同等保护中。官方 Shell 文档也写明，沙箱模式描述的是文件效果。其他风险仍要由工具策略、执行环境和部署配置处理。

danger-full-access 的含义也不能只写成“更快”或“高级模式”。它允许动作跳出工作区，审批策略还可能不再打断执行。用户在个人测试机上临时选择，和管理员把它设成团队默认值，风险完全不同。

权限预设的变化还涉及时间。DeepSeek Harness 的插件说明显示，设置页面改变的默认预设主要影响之后创建的会话。已有会话会保留开始时固定的权限事实，不会因为管理员后来修改默认值就自动变化。

这种处理保护了任务的一致性。一个运行到一半的 Agent 不会突然获得更大权限，也不会因为全局设置收紧而在没有说明的情况下改变行为。它同时带来管理问题。管理员已经把默认值改成更谨慎的模式，旧会话可能仍按原权限继续。

产品需要告诉管理员改变从什么时候生效，并提供查看旧会话权限的办法。涉及高风险修订时，管理员可能需要终止或重新创建已有会话。只在设置保存后显示“修改成功”，会让人误以为所有运行中的任务已经更新。

自定义权限状态也需要被看见。官方预设服务会根据沙箱和审批的实际组合推导当前状态。当两项设置不再匹配任何命名预设时，界面会得到 custom。这个状态不能只显示成一个让普通用户摸不着头脑的英文词。页面应该把当前文件范围和审批规则分别写出来。

审批失败也有不同含义。用户拒绝，表示人作出了决定。审批通道不可用，可能是当前客户端没有能力处理。请求被取消，可能来自会话中断。把它们统一写成“权限不足”，模型可能不断重试，用户也不知道该去修改设置还是重新发起任务。

DeepSeek 的 Bash 工具文档还规定，Agent 遇到真实的沙箱拒绝后，可以在同一轮用最小必要权限重试一次，并提供理由。这个约束值得产品团队参考。提权应由已经发生的具体拒绝触发，理由要和原动作相连。Agent 不应在任务开始时预先要求最高权限，只为了减少后续麻烦。

一次性授权结束后，界面最好给出结果。命令是否真的执行，使用了哪种范围，有没有产生文件变化。用户批准只代表愿意让动作尝试，不代表动作已经成功。审批记录和执行结果需要连在一起。

执行记录要记住当时发生的事实

Agent 完成任务后，用户通常会问它改了什么。让模型重新生成一段解释很方便，这段解释可能遗漏失败尝试，也可能把原本没有发生的检查写进总结。

执行轨迹记录的是任务当时发生的事件。工具接收了什么参数，返回了什么结果，哪一步被拒绝，哪个子任务加入了新上下文，都应该有对应记录。

DeepSeek Harness 采用追加式会话日志，旧事件不会为了迎合后续结果被直接改写。继续会话、搜索和重放都基于同一条事件流。这样的记录方式适合处理一个常见争议。最终结果有问题时，团队可以回到当时的输入和工具结果，判断故障来自模型选择、工具实现、权限策略还是环境状态。

产品展示不必把全部底层事件一次性倒给普通用户。可以先呈现任务进度和关键动作，在需要排查时展开详细记录。面向团队管理员，还可以增加工具名称、执行耗时、审批人和失败类型。不同角色看到的层次可以不同，底层事实应保持一致。

这类记录也会改变产品指标。

单看任务最终成功或失败，很难指导改进。执行轨迹能进一步说明任务在哪一步停住，用户拒绝了什么动作，哪一种工具最容易返回异常，重试以后是否恢复。模型评估由此进入具体过程，产品团队也能找到值得优先修复的环节。

执行事实还要区分几种常见失败。

命令返回非零状态，说明程序运行了，只是结果不符合预期。沙箱拒绝表示动作触碰了当前范围。审批被拒时，命令根本没有开始。沙箱运行器不可用，则是执行环境在命令开始前出了问题。任务超时和用户主动取消又是另外两种情况。

用户界面若把它们全部归为“执行失败”，恢复动作会变得混乱。代码测试失败，Agent 应该读取输出并修改代码。策略拒绝后，它可以请求一次范围更明确的授权。沙箱后端故障需要平台维护者处理，继续让模型换命令通常没有意义。

官方 Shell 文档会分别报告沙箱拒绝、执行完整程度和运行器故障。模型收到这些事实后，可以判断是否允许重试。产品也应该把相同区别交给用户和管理员。底层已经记录清楚，界面没有必要再把它们压回一个红色图标。

失败分类会影响责任归属。模型选择了错误命令，Agent 团队要改提示或策略。工具参数校验失败，插件作者需要修正接口。审批服务没有响应，属于产品基础设施问题。工作区测试本身失败，则可能说明代码仍有缺陷。

团队做周报时只统计“Agent 成功率”，这些问题会混成一个数字。成功率下降五个百分点，没人知道该换模型、修工具还是扩容执行环境。事件流里已有足够信息，指标设计应该保留它们。

回放功能也需要边界。DeepSeek Harness 允许基于同一事件流继续、分叉和重放。重放可以帮助复现问题，外部环境却可能已经变化。文件被更新、依赖版本改变、网页内容消失，完全相同的工具调用不一定得到相同结果。

产品不能把“可重放”写成结果必然复现。它能恢复当时的会话事实和动作顺序，环境能否复原要看沙箱、依赖和外部服务是否留下版本。面向排查的界面最好区分事件重放和环境复现，避免团队对审计能力作出过大承诺。

分叉会话还有权限继承问题。新分支从旧事件开始，应该继承哪些权限事实，是否继续使用原工作区，都要在创建时说明。DeepSeek 的会话设计会把这些持久事实放进事件记录，这让恢复行为有依据。产品仍需把继承结果呈现给用户。

插件越容易替换，责任边界越要写清楚

DeepSeek Harness 当前最醒目的设计，是模型、工具、技能、会话、沙箱、存储、循环、调度和界面都可以作为插件组合。开发者可以通过配置选择或替换能力，无需改动 Harness 的核心代码。

这种自由度适合团队搭建自己的 Agent。公司可以接入内部模型，替换远程沙箱，增加专用工具，也可以保留适合组织规则的审批方式。

产品风险会随着可替换能力一起增加。

一个新工具能读取哪些数据，会把内容发往哪里，运行失败后留下什么状态，都不能只靠插件名称判断。一个更换后的存储插件是否保留完整日志，一个外部模型是否接收敏感上下文，也会影响原有的安全承诺。

平台因此需要一份可读的能力说明。管理员在安装插件前，应当看到它申请的文件、网络和进程权限，了解数据是否离开本地。插件升级改变权限范围时，产品也应重新提示。团队还需要知道出现故障以后该找插件作者、平台维护者还是内部管理员。

插件化让能力组合更灵活，也把系统设计责任交给了使用者。DeepSeek Harness 仍处在开发者预览阶段，官方明确提醒核心插件和接口还会变化。企业若把它用于内部试点，版本兼容、权限复核和故障处置都应该进入上线计划。

工具进入 Harness 以后，还会经过一条可扩展的执行流程。官方的工具开发说明给出了几个位置。动作执行前，策略可以选择允许、拒绝或询问。最终保护可以继续收紧结果，后续监听器不能把已拒绝的动作重新放行。执行环节可以加入超时、重试和指标记录，动作结束后还能调整展示内容或阻止敏感结果回到模型。

这些机制落到产品上，就是一组管理规则。

公司接入一个查询客户信息的内部工具，可以在执行前检查当前用户和任务范围。返回结果里若包含超出权限的字段，结果处理还要阻止它进入模型上下文。一次调用耗时过长，执行层需要停止并说明超时。管理员希望统计调用量，可以在不改变工具结果的情况下记录事件。

每个环节都可能由不同插件贡献。系统若允许后安装的插件覆盖前面的拒绝，权限规则就不可靠。DeepSeek 文档中的最终单向拒绝机制，保证后续逻辑只能继续收紧，不能把已经禁止的动作恢复为允许。这种顺序应该进入平台的插件规范，也应该经过自动测试。

产品经理在规划插件市场时，常会先想到安装、搜索和评分。Agent 插件还需要展示执行位置。它是在动作前判断，包裹实际执行，还是处理返回结果。两个插件同时处理同一类动作时，先后顺序会不会改变结果。这些信息决定管理员能否评估组合风险。

插件的描述也不应只写“让 Agent 访问某某系统”。更有用的说明包括它读取哪些字段，能否写入或删除，是否访问外部网络，返回内容会不会进入模型，以及日志保留在哪里。普通用户可以看到简化版，管理员需要完整清单。

升级同样要处理权限变化。一个最初只读的插件，新版本增加写入动作，自动更新就会扩大原有授权。平台可以要求插件声明能力变化，管理员重新确认后再启用。没有变化时，版本升级不必反复打断团队。

插件卸载也可能留下状态。存储插件保存的会话在哪里，调度插件创建的任务是否仍在运行，外部系统里的令牌有没有撤销，都要有清理规则。插件从界面消失，只说明组件不再加载，不代表它产生的数据和外部任务一起消失。

“一切皆插件”给了团队很大自由，也让产品不能用一个统一品牌替所有插件背书。平台要说明哪些能力随官方发行，哪些来自社区，企业自己维护的插件也要有清楚标记。出现事故以后，用户应当知道去哪里查看记录和报告问题。

上线前先用一条任务完成验收

团队评估 Agent 时，常常从功能清单开始。支持多少模型，有多少工具，能否创建子任务，都容易展示。进入工作场景后，一条完整任务更能暴露问题。

可以选择一个范围清楚、结果可核对的内部任务。让 Agent 读取指定项目，修改一个小问题，再运行已有测试。开始前确认允许访问的目录和网络规则，执行中记录每次审批，结束后检查文件变化、测试结果与完整轨迹。

这次验收要回答几个很朴素的问题。

用户能否在动作发生前看懂风险。Agent 失败后能否从明确位置恢复。管理员能否从日志判断故障来源。任务结束以后，工作区里有没有无法解释的变化。

如果这些问题没有答案，增加更多工具只会扩大排查范围。

同一条任务还可以放进不同权限设置中重复执行。只读环境能够完成分析，却不能写入修改。工作区写入模式可以改动指定文件，遇到外部网络请求时仍要停下来。比较任务完成率之外，还要看审批次数、失败位置和人工复核时间。

这种验收能帮助团队找到合适的默认值。权限过窄，Agent 很难完成任务。权限过宽，用户看不清实际风险。产品经理要做的，是根据任务类型给出一个用户能够理解的范围，再用真实运行记录检查这个范围是否有效。

一条任务跑通以后，还不能直接扩大到整个团队。试点应该继续回答稳定性问题。

同类任务重复十次，Agent 是否总能找到正确工作区。失败以后重新运行，会不会重复写入或留下两个版本。用户中途改变目标，旧计划和后台进程能否停止。会话恢复以后，权限与上下文是否保持原样。

这些问题很少出现在产品演示里，却会决定日常使用成本。一次成功可以说明能力存在，重复任务才能说明团队能否依赖。

试点样本也要按风险分开。代码解释和文件修改面对的责任不同，生成测试与执行部署也不能放在一个成功率里。团队可以从可回滚、影响范围小的任务开始，等失败处理和审计流程稳定后，再考虑更高权限场景。

人工复核时间是一个容易漏掉的指标。Agent 把十五分钟的修改压到三分钟，用户为了确认它做过什么又花二十分钟，任务没有变快。轨迹太粗，用户要自己翻文件。轨迹过细，人会被大量无关事件淹没。产品需要找到适合当前角色的摘要层次。

审批次数也不能单独追求越少越好。减少重复、低风险的询问可以改善体验，把所有动作放行只是把风险移到任务结束后。更有用的指标是每次审批是否对应可理解的边界，以及批准后动作的成功率。

恢复能力可以单独衡量。任务在第六步失败，用户能否从那里继续，还是只能重跑前五步。重跑会不会重复外部写入。恢复需要多少人工说明。Agent 运行时间越长，这类成本越容易超过模型调用费用。

团队还要给停用留出路径。发现某个插件有问题时，管理员能否立即阻止新调用，正在运行的任务怎样结束，历史会话能否继续读取。上线计划只写怎样启用，出了事故以后往往只能粗暴关闭整套服务。