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 运行时间越长，这类成本越容易超过模型调用费用。

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

试点结束时，产品经理可以交付一份很朴素的结果。哪些任务在什么权限下跑过，成功和失败分别发生在哪里，用户批准了哪些动作，出现问题后花了多少时间恢复。它比“支持多个模型和工具”更能帮助负责人决定是否扩大使用。

一张执行责任表应该写什么

文章开头提到的责任表，不需要从完整架构开始。选一条真实任务，沿着动作发生的顺序记录，就能做出第一版。

下面这张表仍以修复登录问题为例。它不代替技术日志，只负责让产品、研发和安全团队在同一页上讨论。

表里最重要的一列是“谁作决定”。模型可以建议动作，不能替用户批准自己获得更高权限。策略可以自动拒绝，也不能在没有规则的情况下替人作业务判断。用户负责例外授权，产品要给他足够信息。

“系统需要留下什么”决定了以后能不能查。文件编辑只有最终差异，没有工具参数，团队可能不知道 Agent 为什么改这里。审批记录只有“已允许”，没有对应命令，也无法证明授权覆盖了什么。每条记录都应和具体动作关联。

责任表还要写失败后的下一步。读取失败可以让用户确认工作区。策略拒绝可以由 Agent缩小动作，必要时再申请一次性权限。测试失败应当回到代码和输出。执行环境故障则交给平台维护者。恢复路径与失败类型对应，用户就不会在同一个按钮上反复重试。

团队换一种任务时，这张表也要跟着变。

只做代码解释，文件修改和提权阶段可以删除，重点改成读取范围和敏感信息处理。生成一份需求文档，写入对象可能从代码文件变成协作文档，审批人也可能从操作者变成文档所有者。Agent 触发线上发布时，责任表还要加入环境选择、发布窗口和回滚确认。

产品经理不必追求一张表覆盖所有 Agent。先覆盖团队准备开放的任务，已经足够。每增加一种工具或更高权限，再检查表里多了哪个决定，谁来承担。

责任表也能帮助团队审查默认权限。如果多数任务只需要读取和工作区内写入，默认开放全盘访问就缺少依据。如果某类任务每次都在同一步申请相同权限，团队可以考虑建立更窄的固定规则，减少重复审批。

上线以后，表中的记录项可以直接变成验收要求。界面是否显示当前工作区，提权是否绑定一次调用，命令没有执行时能否区分审批拒绝和环境故障，任务结束后是否提供测试证据。每一项都能通过实际操作检查。

它还适合处理跨团队争议。安全团队说风险太大，产品团队认为审批已经足够，研发团队担心日志影响性能。把争议落到具体动作，三方可以讨论哪些记录必须实时保存，哪些内容按需展开，以及什么权限可以由策略自动处理。

一张好用的责任表不会让每个人都负责。它会把决定放到能够承担后果的人那里。重复、低风险的动作交给明确策略，高风险例外交给用户或管理员。模型保留提出动作和处理结果的能力，执行环境负责守住已经确定的范围。

评审这张表时，可以请每个角色只回答自己负责的那一列。产品经理说明用户在什么时候作决定，研发确认记录是否真的能够取得，安全人员检查默认范围，运维说明执行环境故障怎样被发现。任何一项只能回答“到时候看日志”，都说明当前产品还缺一个可见入口。

责任表需要跟版本一起更新。插件增加能力，权限默认值改变，或者会话恢复方式调整，原来的决定位置可能已经变化。把它当成一次上线文档，很快会失效。把它放进高风险功能的评审和验收，才会持续有用。

产品页面还缺哪几块

很多 Agent 产品已经有聊天框、计划列表和运行状态。要进入团队工作流，还需要补上几块与执行责任直接相关的界面。

任务开始前，页面要说明当前工作区和主要权限。敏感动作出现时，审批信息要覆盖实际影响。任务进行中，用户应当看到关键步骤和异常位置。任务结束后，结果要能回到文件变化、工具输出和测试证据。

管理员需要另一层视图。他关心插件来自哪里，调用了哪些外部服务，策略为何放行，以及同类失败是否在重复发生。把管理员信息全部塞进普通用户界面会造成干扰，完全隐藏又会让团队无法治理。

DeepSeek Harness 展示了一种可能的组织方式。执行事实留在同一条事件流里，产品根据角色提供不同查看入口。用户关注任务是否安全完成，开发者关注工具与插件怎样运行，管理员关注权限和数据去向。

这几类界面可以围绕同一项任务组织。

普通用户首先看到任务当前在做什么。涉及文件修改时给出差异，遇到权限请求时说明影响，结束后展示结果和验证证据。用户需要追问时，再展开工具记录。

开发者需要知道模型为什么选择这个工具，参数经过哪条策略，执行环境返回了什么事实。工具结果被截断或替换，也要有清楚标记。否则他会把展示层处理误判成工具本身的问题。

管理员关心的是跨任务规律。哪些插件调用最频繁，哪种权限最常被拒绝，哪些任务请求过工作区外写入，外部服务接收了多少数据。单次轨迹提供证据，聚合视图帮助他发现反复出现的风险。

安全负责人还会追问数据流。模型提示里包含哪些文件内容，工具结果有没有传给外部模型，日志保存多久，谁能导出。DeepSeek Harness 的安全使用政策提醒用户，插件、MCP 和其他外部工具可能处理或传输数据。团队不能只因为 Harness 本地启动，就推断全部数据都留在本机。

这也是“本地 Agent”宣传中最容易产生误解的地方。界面运行在本地，模型可能来自云端，搜索和插件也可能连接外部服务。产品应当按每次调用展示数据去向，至少让管理员能够配置和审查。

凭据管理需要单独处理。Agent 为了调用模型、代码平台和内部系统，会使用不同令牌。插件不应默认读取所有环境变量，日志也要避免把密钥写进工具输出。权限责任表里应当标出凭据由谁提供，在哪个执行环境可见，撤销以后哪些会话受到影响。

团队采用 Agent 的第一个买单人可能关注效率，最终能否上线还要经过安全、法务和运维。产品经理若只准备功能演示，后面的审查会不断补材料。把权限、数据、日志和故障处置一起放进试点，采用决策会更接近真实成本。

写在最后

DeepSeek Harness 目前仍是面向开发者的预览产品。普通用户未必需要理解 Cordis、插件挂载和运行模式，也很难直接把它当成成熟的企业 Agent 平台。

它给产品经理留下了一个具体任务。Agent 一旦能够改变真实环境，产品设计就不能停在输入框和答案卡片。模型提出了什么动作，策略为什么允许，工具实际影响了哪里，用户在何时确认，失败之后如何恢复，都要进入产品图。

一张执行责任表可以从一条任务开始。把用户、模型、工具、策略、沙箱和管理员放回同一段过程，标出每一步的输入、决定、结果和记录位置。画完以后，许多原本藏在“自动完成”里的空白会显现出来。

模型能力决定 Agent 能提出怎样的下一步。执行层决定这些动作能否被看见、限制和核对。团队愿不愿意把工作交给 Agent，依赖的正是后面这些安排。

关键资料：

• DeepSeek Harness 官方页面
• DeepSeek Harness 官方架构文档
• 官方会话子系统文档
• 官方工具执行流程文档
• 官方沙箱文档
• 官方权限预设文档
• 官方能力边界文档
• 官方 Shell 子系统文档
• 官方新增工具说明
• DeepSeek Harness 安全使用政策
• DeepSeek Harness 数据处理声明