dsh-superagent/docs/000-理念.md

000 理念

dsh-superagent 是一个框架，也是一种与 agent 协作的方式。它的核心原则：

尽量少地占用人的注意力，尽量多地交付价值。

项目的每一处都按它花费的注意力来评判。一条消息、一次通知、一个问题、一个设置、一个面板元素、一段文档，各自都要消耗某个人的注意力，各自都必须给出比这更多的价值，否则就删掉。

agent 要遵守的

• 它只在被要求、或被写下的规则允许时才行动。 只有直接面向 agent、且来自团队允许的人的请求才算数：允许名单上的人，或团队开放给请求的会话里的任何人。没人要求的工作需要团队写下的规则，并且以只记录 agent 本会做什么的模式开始。
• 它只在有人必须行动、或用得上结果时才说话。 它确认一次请求，并说明它将做什么。干活期间保持安静。有结果、需要决定、或无法完成时再写。消息简短，发到提出请求的那个对话。
• 它一次只问一个具体问题， 用结构化表单，让问题到达人那里，而不是埋在一长段报告里。
• 它按影响停下，不按费力程度。 本地改动推进到可评审的结果为止。需要设计决定的改动停在一个清楚的问题上。
• 它如实汇报。 草案标未完成，失败按失败报告，绝不为了少问一句而绕过限制。

设计要遵守的

• 概念少。 设计里只有它的领域概念（例如 Source）和这些概念的具体实现（例如 GitHub 和 Feishu）。一个业务需求要么变成其中某个概念的属性，要么变成 agent 遵循的一段提示词。设计不为此新增概念。
• 设置少。 当一个取值几乎适合所有团队时，用默认值代替设置。团队用语言描述的行为是提示词文本，不是设置。
• 面板只显示需要人的东西。 它先列出等待人的事项。健康的状态不占空间。
• 文档按顺序读。 每篇编号文档只建立在前几篇之上，读者永远不会遇到一个还没引入的概念。

责任

agent 以你们团队天天见到的账号发评论、开 pull request、给人发消息。它发出的每条消息都消耗你同事的注意力，你要为此负责。agent 能做得越多，操作者对团队就越要多留心：

• 从窄处开始。 先用一份短的允许名单，主动工作只做记录。等 agent 本会做的事看起来对了，再放宽这两样。
• 往噪声更少的方向调。 agent 太吵时，把它的提示词改短、改严，或者暂停它。不要为了解释噪声而多发消息。
• 不要拿它堆产量。 大批量 pull request、群发消息、刷出来的活儿，团队亏的比赚的多。
• 替它说的话负责。 读 agent 以你的名义发的内容，发现不对就在提示词里纠正。

目标是恰好的帮助出现在恰好的时间，其余时间什么都不出现。