dsh-super-agent的思考

最近正在做AI员工，所以，当看到dsh-superagent-prototype的时候，就关注了一下，虽然当前实现主要针对单个 GitHub 仓库的软件开发任务，但是有些思路可以借鉴。

为什么要做AI员工呢？

1. 经过半年多迭代，AI Code SOP已经很成熟，编码几乎能够委托给AI；自动化、自进化自然提升日程。
2. 个人注意力是有限的，要只保留最少判断。
3. LLM和Agent成熟度越强越高。

##　Dsh Superagent Prototype 值得关注的点 不是说我聪明到可以和Deepseek大牛相比，只是很多工程化思路都很相似。

1. Router / Worker：员工身份与工作会话分离 DeepSeek 认为，用户不应该管理 Session。Session 是技术实现细节，不应该成为用户的工作管理单位。Agent部分我会外包给codex、workbuddy、豆包甚至千问，对于OPC，试图跨过这个边界几乎没有意义。
2. Trigger → Eval → Ticket DeepSeek 更关注什么事件有资格变成工作。
   1. Trigger：发现新事件：运营数据变化、评论、定时检查
   2. Eval：规则过滤 + LLM 判断是否值得处理
   3. Mandate：确认工作范围以及获得了什么授权
   4. Ticket:形成具体工作任务
   5. Assignment： 分配给执行 Agent，完成或等待反馈 官方原型还提供三种主动工作模式：off、observe、auto。默认 observe 只记录“如果允许自主执行，我会做什么”，不真正执行。
3. 人的注意力是主要优化目标 DeepSeek 官方的核心原则是：

Take as little human attention as possible, and give as much value as possible.

它把通知、提问、设置项、管理页面乃至文档，都看作会消耗人的注意力的东西。 这个对我的影响很大，真正决定 AI 员工是否有价值的指标还应该包括：

每交付一项有价值的成果，需要占用老板多少注意力？

既要也要不成立，我的注意力就那么多。一种是积极放权；一种渐进放权。后者可能更适合我，产品不成熟，llm和agent还在进化。

4. Watchdog：监督结果，而不仅是监控进程 DeepSeek 提出了独立的 Watchdog 监督机制，既监控基础设施错误，也利用模型判断 Worker 是否产生实质进展、是否偏离目标。 与我的Verification 和 Self-improvement 思路很接近。

但现阶段不需要另起一个 Watchdog Agent。可以先让 Beta 在每次工作结束时记录目标、结果、证据和偏差，并在下次工作前检查未解决问题。

我的逻辑

1. 不要过度设计，不要复杂架构
2. 不要越界
3. 不着急