讨论：Agentic Bot 团队最佳实践、功能目标与 Benchmark

[Liyuk]

讨论定位：Best Practice + 后续功能目标与 Benchmark

本帖首先希望一起探索 DS Bot 的团队协作和长任务最佳实践：什么样的沟通、角色、交接、验证和恢复方式能帮助用户更稳定地完成工作。它不是已经决定实施的功能清单。

在积累真实使用经验后，再将有效做法转化为明确的产品和 harness 改进目标，并建立可重复的 benchmark：先测现有基线，再用相同任务和验收标准衡量改进对交付成功率、可靠性、用户干预、耗时和成本的影响。具体功能、指标及取舍仍需社区和维护者讨论。

背景：群聊怎样真正提升任务完成率？

DS Bot 的愿景是长期存在、能协作的 Bot 团队。Grok Bot 的公开资料也提出围绕共同目标开展群聊、明确每个阶段的负责人，以及按需交接给专家（协作指南）。这些是值得借鉴的产品思路，但并不证明多 Bot 一定比单 Bot 更可靠。

想讨论一个更完整的方向：用户从群聊提出目标后，经过多 Bot 讨论、工具调用、上下文压缩、派活以及中断恢复，团队能否持续理解用户最新意图，最终交付可验证的结果？ 这既涉及 Bot 的协作和角色，也涉及底层 harness 的运行能力。

相关讨论：#652：提升 Bot 的目标理解、任务交付和自主恢复能力。这篇更聚焦群聊作为输入、团队协作和跨层运行体系。

现状：已有基础，也有待验证的边界

以下基于现有设计、代码和部分测试的阅读；风险不等于已经复现的故障。

• 群聊已有管理员先答、@ 路由、长工作后台继续和迟到结果回群；群里的活留在群里，群内 message_bot 等同 @。但成员有各自的会话和有限的历史输入，长讨论或用户改目标后，团队是否仍对同一个目标有一致理解，值得实测。群聊设计
• 上下文已有检查点、换段交接、历史保留和检索；交接会要求记下目标、约束、进度和未完成事项。但摘要由模型生成，无法保证没有遗漏；近期消息存在预算和截断，溢出或交接失败时可能没有笔记。上下文与记忆
• 派活已有私聊派活树、持久化等待、请求去重和子结果返回；群内 @ 按群聊规则运行，不进入这棵树。已定设计也记录了可能持续互问、返工或无限等待的风险。派活设计
• 中断恢复已有回合和待处理消息的恢复、重启后的结果结算；无法确定结果时会说明未知，避免盲目重跑。但回合恢复不是对外部工具副作用的事务保证，也不等于整个任务已经验收。恢复代码
• Harness 边界：Bot 会话当前禁用 DSH goal；让步总账还记录了模型流卡住和工具结果截断等限制。具体问题是否仍存在、公开 API 能提供什么，实施前需要核实。DSH 让步总账

想法一：群聊是任务入口，重要任务有可追溯的工作状态

对复杂任务，探索从群聊形成一份精简、可检查的任务状态，在需要时帮助成员理解：

• 用户最初的目标和原话位置，以及后续的修正；
• 当前范围、约束、授权边界、预期交付和验收标准；
• 当前负责人、已做和未做的工作、阻塞与下一步；
• 重要判断、证据来源、尚未解决的分歧与不确定性。

应区分用户确认的决定、Bot 的建议和外部材料；保留原消息来源，避免模型摘要把推测变成事实。用户改变方向后，迟到的结果应保留其原来的任务背景，由负责人判断是否仍适用。群外私聊和记忆不应自动广播到群里。

这不一定要做成任务看板或结构化任务对象。可以先用现有群聊和提示词试验，看看这种状态是否提高成功率。如何存储、更新、处理冲突和跨段恢复，都是开放问题。

想法二：借鉴协作原则，不机械模仿人类岗位

Bot 都比较全能，只有「研究员」「工程师」这样的人设容易失去区分度。可以把长期身份与本次任务职责分开：

• 长期身份体现在关注点、熟悉的上下文、能力、权限和交付习惯；
• 一次任务里明确谁对最终交付负责，谁提供某项专业支持，谁在需要时独立审查；
• 专业可以重叠，但下一步和交付的责任应清楚；不要求所有 Bot 都发言；
• 不设置永远唱反调的角色；用证据、反例和验收标准形成有价值的不同视角，并保留重要分歧。

小任务可以由一个 Bot 完成；可独立拆分的研究可以并行；单一产物可以由作者完成后按需交给审查者。负责人通常汇总关键结果，专家在发现重大分歧、阻塞或需要用户决定时直接在群里说明。如何避免汇总丢失分歧，同时减少重复汇报和 token 消耗，值得讨论。

想法三：以交付而不是回复结束工作

任务执行应持续对照用户的最新目标：明确交付物和完成标准，增量推进，验证结果，遇到真正需要用户决定或授权的地方再提出具体问题。最终区分完成、部分完成、等待用户和结果未知，并给出产物位置、验证依据、剩余问题与下一步。

长任务恢复时先检查真实产物和外部状态；不能确认副作用是否发生时，不盲目重复操作。也可探索识别长期无进展、重复讨论和预算消耗，让用户看到可恢复状态；具体机制需要和现有已定设计一起讨论。

Anthropic 的长任务 harness 研究在软件开发实验中发现，仅靠上下文压缩仍会出现半成品遗留或提前宣布完成，使用进度记录、增量工作和验证可以帮助恢复。该结果不能直接证明其他任务或多 Bot 同样受益。

想法四：Bot、团队层与 harness 各自负责什么？

• Bot：理解问题、使用专业知识、制定策略、解释结果。
• 团队层：群内路由、负责人、交接、共享任务状态与可见进度。
• Harness：在 DSH 公开能力范围内处理工具执行、权限、事件、取消与恢复等运行保障。
• 界面：让用户能检查和纠正目标、证据、阻塞和交付。

现有设计明确使用 DSH 标准 harness，且派活设计不做任务看板。这些想法若改变已定设计，应由维护者决定。先确认 DSH 公开插件 API 能支持什么；缺少的能力向上游提出，不 patch DSH 或依赖安装内部文件。

建议先做基线实验

对同一组任务比较单 Bot、当前群聊和带明确任务简报的群聊，至少覆盖：可验证产物、多专家协作、用户中途纠正、迟到结果、换段、重启，以及外部工具效果未知。记录：

• 主要指标：最终交付是否满足用户最新目标和所有必需验收标准；
• 约束丢失或误归属、重复工作或副作用、恢复效果、证据质量；
• 用户干预次数、耗时和 token 成本。

以独立的任务检查和必要的人类判断为准，不只看 Bot 是否声称完成；重复运行并记录版本和差异。对注定受阻的任务，评估是否正确说明阻碍，而不是强行判为完成。先建立基线，再决定哪些改进属于提示词、团队机制或 DSH 上游。

从最佳实践到功能目标

建议先收集真实任务和可复用的团队工作方式，形成最佳实践；再识别仅靠使用约定不能解决的问题，提出有明确目标的功能或上游需求。每项候选改进都尽量说明要改善的失败场景、预期用户结果、benchmark 案例及与基线的比较方式，避免为流程或角色本身增加机制。

希望讨论

1. 现有 DS Bot 在真实任务中有哪些值得推荐或应避免的协作最佳实践？
2. 群聊是否需要一份跨 Bot、跨段的任务状态？哪些信息必须保留，哪些应继续留在自然对话中？
3. 默认由一个负责人汇总、专家在关键时刻直接发言，是否适合 DS Bot？如何处理用户改方向和迟到结果？
4. Bot 人设怎样在全能模型下保持有用区别？哪些角色差异需要真正的工具、权限或验收约束？
5. 长任务的完成、停止、阻塞和恢复应如何定义？哪些能力应该属于 DSH，哪些应该属于 DS Bot？
6. 哪些真实任务最适合作为首批基线，验证团队协作是否实际提高交付成功率？

[Liyuk]

补充一份参考：Grok Bot 客户端与协议逆向分析。它针对桌面客户端 0.70.2，能看到成员回合请求中有新消息、截止时间、因果链，以及发言、跳过、超时等结果；具体服务端调度策略仍属于推断或未知，不能据此认定 Grok Bot 的完整实现。

对照 DS Bot，现有群聊已经有管理员先答、@ 接力、PASS、后台工作和迟到结果；消息也有 exchange 标识和重启恢复。可以把这份资料转化成几个更具体的 benchmark 场景，而不是先增加新的编排机制：

1. 成员未完成回合：成员超时、等待审批或仍在后台工作时，用户和发起 Bot 能否区分这些状态？迟到结果能否回到原群并保留原任务背景？
2. 投递与恢复：接收方忙碌、应用重启或消息状态不确定时，发起方能否知道消息仍在等待、已被取走、失败或结果未知？恢复时是否避免重复交付？#668 是一个相关的具体问题。
3. 用户中途改方向：新要求到达后，尚未处理的工作和迟到结果如何关联原目标？负责人能否判断结果是否仍适用？
4. 控制成本和循环：同一任务反复 @、成员 PASS 或接力达到限制时，群里是否能看清发生了什么、如何继续？

可以先固定版本，用相同任务记录最终交付、丢失或重复的消息、错误状态、用户干预、耗时和 token 用量。只有实测发现缺口，再决定是改 DS Bot、向 DSH 提需求，还是改善使用约定。

[Liyuk]

承接本帖"先测基线、再用相同任务和验收标准衡量改进"的思路，补一份可操作的指标与回归做法。与 #652 的方案配套：那边讨论改进方向，这边讨论如何衡量。

一、先明确"交付完成"的定义

建议将完成定义为：产物存在且通过可执行检查；涉及价值判断的项由用户明确确认。 模型自行说明"已完成"不计入完成。

由此可得到两个可度量对象：

• 完成率：交付的产物中通过检查的比例；
• 虚假完成率：声称完成但检查未通过的比例。后者可与完成率并列观察。

二、建议的指标

指标	定义	现状
虚假完成率	声称完成但检查未通过 / 声称完成总数	无检查机制，暂无法度量
派发一致性	声称已派发但无派发调用的次数	实测中出现过
重复执行率	同一任务被重复创建 / 同时执行的实例数	实测中出现过
停滞检出时延	从无进展到被标记为停滞的时间	暂无机制
用户干预次数	用户催办、纠正、重复说明的次数	长任务中较常见
交付物可用率	产物可直接使用（无需返工）的比例	未度量

建议同时记录耗时与 token 成本：若可靠性提升以数倍成本为代价，需要明确取舍。

三、回归用例建议

建议使用真实场景而非人造任务，至少覆盖：

1. 多角色协作任务：需要分派给多个角色、有明确产出物、中途用户追问进度。关注点：被派发者是否真的被唤醒；计划人数与实际执行人数是否一致。
2. 数据管道检查任务：要求核实某条流水线能否实际跑通。关注点：是否执行了检查而非只看文件是否存在；结论是否有执行证据。
3. 中断恢复任务：在长任务进行中重启或压缩上下文。关注点：目标、验收标准与已完成部分是否保留。
4. 用户中途改目标：关注团队是否按最新指示调整，而非继续原计划。

四、方法

• 每个用例记录：原始目标、最终产物、检查结果、用户干预次数、耗时与成本。
• 基线组使用当前版本，实验组使用改进版本，保持同一任务与同一验收标准。
• 判据应为检查输出或用户确认，模型生成的总结不作为成功依据。
• 单次结果不足以说明因果关系，建议重复试验并观察分布。

这套指标的一个用途是检验方向：若引入机制后虚假完成率没有下降，可据此判断该机制是否有效，再决定继续或调整。