从 DeepInfer 到 DeepSeek Harness：给 Agent 划一个可审计的范围
第一个问题不是选哪个模型、接哪个 API，而是：这个 agent 只允许完成哪一件任务，它能读什么，能改什么，不可逆的那一步由谁批准。
本文是由 SpringBrand 提供的、明确标注的客座文章。SpringBrand 没有参与本站其他页面的编辑，文中的技术主张都链接到一手资料。本站仍然是独立、非官方的资料站。
上一篇客座文章画出了栈：模型、DeepInfer 这样的推理引擎、DeepSeek Harness 这样的 agent harness，以及 agent 能调用的工具。这一篇往下走一步，把那张图变成一次真实部署的范围表。
多数团队一开始问错了问题：哪个模型最聪明、哪个 API 连接器最多、怎样在周五之前把 agent 跑起来。这些问题后面再问。第一个问题要窄得多：这个 agent 只允许完成哪一件任务，什么证据能证明它完成对了？
这个问题也是最便宜的失败点。一个任务含糊、工具权限很宽的 agent，不是生产力胜利，而是一场等着发生的 incident——而审批人从没见过它准备执行的动作。下面这套方法，就是在 agent 跑起来之前把边界画出来。
一个任务，一个终点
“研究一下我们的竞争对手”不是任务。它没有停止条件，没有可接受的产出，也无法区分一份有用的简报和一堆看起来合理的段落。把它收窄之后，听起来没那么宏大，但能跑：
“针对三个指定的预约类产品，比较它们公开帮助页面对多门店支持的说法。输出一份 300 字简报，每条主张附来源链接和抓取日期，列出页面没有回答的问题，然后停止。不要联系厂商，不要使用客户数据。”
这个范围写明了输入、产出、证据和停止条件，也让审批点变得清楚：市场负责人在简报变成定位文案之前审阅。研究任务内部不发生任何外部动作。
换成 coding agent，等价物是仓库路径、测试命令和完成定义。换成客服 agent，是一个工单类别、允许的回复集合和转人工规则。形状会变，纪律不变。
工具契约
任务收窄之后，列出它真正需要的工具。不是厂商有多少工具，也不是团队下个季度可能会用的工具，而是把这件事从输入推进到“可审阅产出”的那两三个连接。
写这份清单时，按后果分类，而不是按产品名分类：
| 动作类别 | 含义 | 例子 |
|---|---|---|
| 读 | 获取已批准的来源或记录，不改变状态。 | 抓取公开帮助页；读取一条 CRM 记录。 |
| 准备 | 起草、比较或打标，不对外发布。 | 起草简报；建议一个 CRM 字段更新。 |
| 写 | 修改记录或发送内部产物。 | 保存笔记；创建工单草稿。 |
| 不可逆 | 对外发送、发布、付款、删除或授权。 | 给潜客发邮件；发布页面；退款。 |
多数第一次部署应该停在“读”和“准备”。这不是保守，而是先验证检索质量，再决定要不要给它行动能力。SpringBrand 那篇梳理 agent 需要连接哪些工具的文章，从另一个方向说了同一件事：从一个业务问题开始，先解析账户或来源，只在任务需要时增加连接。
契约还要写清工具失败时怎么办。查询超时不等于“没有记录”；凭据过期也不等于空结果。如果任务分不清这两种状态，审阅者就无法判断他看到的是一个已验证的空白，还是一条断掉的连接。
读与写，是凭据层面的决定
把权限写成 prompt 指令很诱人：“不要删除任何东西。”那不是控制。真正的控制落在凭据、工具 schema 和执行层。
先给 agent 一个只读凭据。确实需要写时，再给它一个独立身份、窄 scope，并把写动作放在没有审批就调不到的工具后面。不要因为方便就复用人管理员的 token。如果 agent 能碰到管理员能碰到的记录，一次 prompt injection 就有同样的触达范围。
SpringBrand 的AI agent 安全指南在这里很好用：先画数据、工具、身份和动作的边界；把读权限和写权限分开；把外部内容当作不可信输入；把授权留在模型之外。最后一条最常被跳过。网页里可以有一句指令，但它不能授予权限。
DeepSeek Harness 在运行时也提供了同样的接缝：scoped 工具注册表、审批策略、沙箱模式和只追加的会话日志。它们不会替代你的访问模型，但给了你执行访问模型的位置。
在不可逆的那一步之前放一个人
审批点不是“流程里的某个地方”，而是不可逆动作之前的最后一步，而且要让审阅者看到即将发生的具体内容：收件人、主题、正文、目标地址、金额或记录变更。
邮件发出去之后再审批，只是通知。发送前三步审批，可能审的是一份中途已经改过的草稿。审阅者需要看到最终要执行的动作，不是计划摘要。
这也是 SpringBrand 那篇human-in-the-loop 工具对比的核心：在后果之前暂停，保留被审阅的版本，把决定和实际执行的动作绑定，并定义拒绝或超时后怎么办。无论工具是 Gumloop、n8n、Zapier，还是自建审批队列，模式都一样。
对 dsh 来说，这落在审批策略和工具调用边界上。如果动作是“发送”，审阅者就该看到那封邮件；如果动作是“发布”，就该看到页面和 URL。“批准这个任务”太粗了。
如果用 bot 团队，先读边界
DeepSeek Harness 的社区插件生态在长。一个例子是 DeepSeek Bot：它给 harness 加上具名 bot、bot 之间的消息和群聊。它不是 DeepSeek 官方产品，也不是使用 dsh 的必需品。
但它是一个有用的案例。SpringBrand 那篇DeepSeek Bot 的角色与边界，把一个研究简报拆给来源收集、比较和起草三个 bot，然后问真正重要的问题：共享记忆放在哪里，卸载后保存的数据怎么办，谁在简报被使用前核对来源？
这些问题会随着 bot 数量放大。bot 团队增加协调和模型用量，不会自动增加覆盖。如果三个助手在复述同一个页面，团队得到的是更多文本，不是更多证据。只有当新角色有独立工作——比如独立核对引用——才值得加。
留一条人能读的审计线索
无法被重建的 agent，不值得托付有后果的动作。至少记录：
- 任务和已批准的范围；
- 调用了哪些工具、输入是什么、返回了什么；
- 模型或提供方版本，以及 harness 版本；
- 谁批准了不可逆动作，他看到了什么；
- 外部结果，包括失败和超时。
dsh 的只追加会话日志，是前三条的天然骨架。审批队列和目标系统负责后两条。关键设计是用一个稳定的 task ID 或 proposal ID 把它们串起来，让审阅者的决定能对上实际执行的动作。
这也是“演示成功”过不了审计的地方。聊天记录里写一句“done”，不能证明 CRM 更新发生了、邮件发出去了，或者审阅者批准的那版内容就是潜客收到的那版。
一页范围表
接第一个工具之前，先把这张表填完。哪一行空着，agent 就还没准备好做那件事。
| 字段 | 写什么 |
|---|---|
| 任务 | 一句话，带停止条件和可接受的产出。 |
| 输入 | 具名来源、账户和记录；明确不做什么。 |
| 工具 | 读、准备、写、不可逆动作，各自对应一个具名工具。 |
| 身份 | 用谁的凭据、哪些 scope、谁能撤销。 |
| 审批 | 人看到的具体动作、谁批准、沉默时怎么办。 |
| 失败 | 超时、拒绝、空结果、部分成功分别怎么表示。 |
| 审计 | task ID、工具调用、审批和外部结果存在哪里。 |
| 负责人 | 谁能停止 agent，谁对数据负责。 |
方法就这么朴素。模型可以换，推理引擎可以换，harness 也可以换；范围、权限和审计线索，才是让这次部署站得住的东西。
想继续看 agent 范围、工具契约和审阅设计，SpringBrand 的agent 工作流博客收了这些例子背后的长文。把它们当设计参考，不要当自己工作流的测试替代品。
常见问题
这是 DeepSeek Harness 的安装教程吗？
不是。这是一套针对单个 agent 任务的范围方法。安装和运行时细节，请从 DeepSeek Harness 官方仓库和本站上一篇客座文章开始。
用 DeepSeek Harness 必须用 SpringBrand 吗？
不需要。dsh 是独立软件，这里的方法也不绑定具体工具。SpringBrand 提供 API、插件和指南；用不用是实施选择，不是前提。
DeepSeek Bot 是 DeepSeek 官方插件吗？
不是。DeepSeek Bot 是社区插件，不属于 DeepSeek Harness 仓库，DeepSeek 也不审核社区插件。使用前请审计代码和权限。
第一次应该接几个工具？
两三个真实任务需要的。更大的目录不会拯救一个含糊的范围。先接读和准备类工具，量出产出，再决定写或不可逆动作值不值得加。
来源
- DeepSeek Harness 仓库 — README、许可证、developer preview 说明、启动命令。
- DeepSeek Harness 架构文档 — profile、bundle、工具注册表、会话日志。
- DeepSeek Harness 安全说明 — 沙箱与审批建议。
- 推理之上的一层 — 本站上一篇客座文章，讲四层栈。
- DeepInfer 的限制 — 为什么推理引擎不是完整服务栈。
继续读：对比总览，或DeepInfer 的架构。