DeepSeek Harness Superagent 设计哲学:把注意力当成最贵的资源

系列第 1 篇。本文是 dsh-superagent 的价值观与设计起点,后面关于领域模型、授权、执行、提示词、面板、部署、架构和扩展的内容,全部由这一条原则推导出来。


一、这个项目的判断标准只有一条

dsh-superagent 既是一个 framework,也是一种与 Agent 协作的工作方式。它的核心原则是:

尽可能少地占用人的注意力,尽可能多地创造价值。

这里有一个反直觉但很关键的判断:一条消息、一次通知、一个问题、一个设置项、一个面板元素、一段文档,每一项都要消耗某个人的注意力。因此,项目里的任何东西都必须能证明自己创造的价值大于它消耗的注意力,否则就应该被删掉。

它不是“先做功能,再想办法收敛”,而是把注意力成本放在设计起点。功能不是越多越好,反馈也不是越频繁越好。一个不说话的 Agent,如果任务能正常完成,可能是最好的 Agent。

是

否

能

不能

一条消息 / 一个通知 / 一个问题

它创造的额外价值
是否大于注意力成本?

保留

删除或收敛

继续追问:
能否用更少注意力得到同样价值?

继续精简

定型

二、对 Agent 意味着什么

只在被要求或被规则允许时行动

一次请求只有同时满足两个条件才算数:

  • 它明确地对着 Agent 发出;
  • 它来自团队允许的人:要么在允许名单里,要么出现在团队已经对请求开放的会话中。

没有人要求的工作,只有团队写了规则才允许启动,而且它必须先进入“只记录我会做什么”的模式,而不是直接动手。

这条规则把“主动工作”从模型拍脑袋变成了团队显式授权。Agent 的主动性被保留,但边界被代码和策略锁住。

只在人必须行动或可以使用结果时说话

Agent 对请求只确认一次,并说明自己会做什么。执行过程中保持安静;只有以下情况才再次说话:

  • 结果准备好了;
  • 需要一个决策;
  • 无法继续完成。

消息要短,并且回到最初请求发生的会话里。不要广播,不要刷屏,不要用长篇报告淹没关键问题。

一次只问一个具体问题

问题要放在结构化表单里,而不是藏在长篇报告末尾。这样问题才能真正到达负责人,而不是被扫一眼后忘掉。

按影响停止,而不是按工作量停止

本地改动推进到“可审阅的结果”就停;需要设计决策的改动,则带着一个清晰的问题停下来。不要因为已经投入了很多工作就继续做不该做的事。

诚实汇报

草稿必须标记为未完成;失败必须报告为失败;绝不能为了避免再问一次而绕过限制。

三、对设计意味着什么

概念要少

设计里只保留领域概念,比如 Source,以及它们的具体实现,比如 GitHub 和 Feishu。业务需求要么变成现有概念的属性,要么变成 Agent 要遵守的 prompt,而不是新增一个概念。

如果一个需求被包装成新实体、新状态、新中间层,先问:它能不能只是现有概念的一个字段?

设置要少

如果一个默认值适合几乎所有团队,就不要暴露成设置。团队用文字描述的行为,应该写进 prompt,而不是变成配置项。

这一点很重要:配置项的代价不只是表单上的一个输入框,而是未来的文档、校验、测试、面板状态和升级兼容性。

面板只展示需要人的东西

面板优先展示“正在等人”的事项。健康状态不占空间。系统正常时,最好的状态是安静;出问题时,每一个元素都必须可行动。

文档按顺序阅读

每份编号文档只依赖它之前的文档。读者永远不需要遇到一个尚未引入的概念。

四、责任始终在人

Agent 会以团队每天都能看到的账号去评论、开 Pull Request、给同事发消息。它的每一条消息都消耗同事的注意力,因此操作者要为这些消息负责。

越强的 Agent,越需要谨慎的运营:

  • 从窄范围开始。 先使用很短的允许名单,并且主动工作只记录、不执行。观察“它本来会做什么”是否合理,再逐步放开。
  • 为减少噪音而调整。 Agent 太吵时,把 prompt 写得更短、更严格,或者暂停它;不要再用更多消息解释之前的噪音。
  • 不要用它制造数量。 海量 Pull Request、广播消息和假忙碌,对团队的消耗大于价值。
  • 为它说的话负责。 阅读 Agent 以你的名义发布的内容;如果它说错了,回到 prompt 中纠正。

目标是:在对的时候提供对的帮助,其他任何时候都不打扰。

五、这一篇对后续内容的影响

如果把 dsh-superagent 当作一个产品,它真正在管理的不是 Agent,而是“人的注意力预算”。

这一原则会依次落成:

  • 领域模型只用 Source、Trigger、Thread、Eval、Ticket 等少数概念;
  • 授权路径把“谁可以开始工作”和“已有工作如何继续”分开;
  • 执行层把 Ticket 状态、后台任务、失败恢复与人的等待统一建模;
  • Prompt 系统把团队可编辑内容收敛到少量 section;
  • 面板优先回答“现在有什么需要我处理”;
  • 部署与运维把每小时检查、状态码和故障恢复做成可操作的最小闭环。

下一篇文章进入领域模型,看这些原则如何变成具体的概念与规则。

Logo

更多推荐