270 lines
23 KiB
Markdown
270 lines
23 KiB
Markdown
# 岗位与项目团队方案
|
||
|
||
日期：2026-10-11。版本：方案 v0.6（首版已接入，长期方向继续讨论）。
|
||
|
||
最新管理设计见 [数字员工项目管理落地方案](ygent-team-management-plan.md)，制度依据见 [项目管理调研](project-management-research-2026-10-11.md)。后续责任领域、参与式规划、任务承接与人员交接按新方案讨论和分阶段实施；当前尚未接入这些新增流程。员工实施统一暂停，早期自动承接说明仅保留历史背景；真实行为以 [进度及 SOP](ygent-team-integration.md) 的最新阶段为准。
|
||
|
||
历史首版状态：按用户要求已接入创建岗位 → 项目入职 → 分配范围 → 自动承接明确任务 → 多轮协作 → 提交验收的 OMP 首版，实际范围与证据见[进度及 SOP](ygent-team-integration.md)。首期采用规则隔离，操作系统沙盒留作后续选项。本文保留后续方向，不代表所有建议已实现；自动承接须用户明确分配任务并启用成员设置，不扩大原有操作权限。
|
||
|
||
## 1. 目标与已明确的需求
|
||
|
||
将当前「专家」改名为「岗位」，支持用户按实际需要定义岗位。各岗位有不同职责、技能及默认模型；项目可以分配岗位，通过「入职」确定其负责内容，再承接和推进工作范围内的任务。
|
||
|
||
希望构建能持续协作的团队，覆盖销售、开发、交付与售后。项目不局限于代码仓库，工作目录也可包含文档、图片及业务材料。成员之间应能多轮提问、补充、交付和返工。
|
||
|
||
必须防止 Agent 为完成自己的目标而越界代做其他岗位的工作。成员在职责范围内完成交付；依赖其他岗位的工作，通过协作请求、任务依赖和交接推进，不能自行扩大负责范围。
|
||
|
||
### 讨论状态
|
||
|
||
| 内容 | 当前状态 |
|
||
|---|---|
|
||
| 专家改名为岗位，配置职责、技能和模型 | 首版已接入，范围见进度及 SOP |
|
||
| 项目分配岗位，通过入职确定负责范围 | 首版已接入，范围见进度及 SOP |
|
||
| 形成销售、开发、售后协作团队 | 用户明确提出的目标 |
|
||
| 岗位模板与项目成员分开，复用任务和对话 | 已获整体方向认可的建议；细节可调整 |
|
||
| 按事件自动承接任务，交付后验收 | 首版按明确负责人及完整条件自动承接，默认关闭；人工验收 |
|
||
| 防止越界，表达跨岗位依赖和交接 | 用户明确要求；首期采用规则隔离 |
|
||
| 文件、Shell、连接器的强制隔离 | 留作后续增强，首期不依赖沙盒；尚未实现 |
|
||
|
||
## 2. 概念保持简单
|
||
|
||
| 概念 | 职责 | 生命周期 |
|
||
|---|---|---|
|
||
| 岗位 | 可复用的职责、方法、技能、连接器需求和默认模型 | 全局定义，可供多个项目选用 |
|
||
| 项目成员 | 某个岗位在一个项目中的具体安排 | 入职后持续存在，可暂停或退出项目 |
|
||
| 项目任务 | 目标、负责人、范围、依赖、进展与验收 | 复用现有项目任务，不随一轮对话结束 |
|
||
| 执行对话 | 某项工作的讨论、工具调用和执行证据 | 可多轮继续，绑定真实成员、任务和运行 |
|
||
| 临时子 Agent | 协助成员处理边界明确的局部工作 | 复用现有协作机制，责任仍归原成员 |
|
||
|
||
界面主要呈现「岗位」「项目成员」。不新增部门、职级或组织架构。按用户新增要求，每个项目默认一位项目经理，专职审核职责、拆解和分配任务，不参与编码，不具备文件修改权限。经理不出现在全局岗位列表，不能删除或禁用；可在项目内修改名称、职责、模型、推理强度和技能，各项目配置独立。
|
||
|
||
项目成员不绑定某个发起对话的寿命。关闭一个对话或结束某次委派，不等于成员离职；暂停成员与取消当前执行应有明确区分。具体取消归属还需结合现有子 Agent / 平级对话机制设计，不能直接照搬子 Agent 的父级取消规则。
|
||
|
||
## 3. 岗位定义
|
||
|
||
建议包含以下配置：
|
||
|
||
- 名称、说明与职责：能处理哪些工作，如何判断交付质量。
|
||
- 技能引用：从已安装技能中选择，复用稳定组件 ID，不重复复制安装。
|
||
- 连接器需求：声明所需服务和工具能力；凭证与实际操作授权独立管理。
|
||
- 默认模型：选择已有渠道、模型及其支持的思考配置；渠道决定请求协议。
|
||
- 工作要求：输出、验证、交接和需要提出澄清的问题。
|
||
|
||
同一岗位可以加入多个项目，但项目中的任务、记忆、对话、授权和运行状态不能因此互通。岗位模板调整应记录版本，并在下一回合边界采用；运行中的模型、目录与能力快照保持稳定。项目是否允许覆盖岗位默认模型、模板更新是否需要成员确认，留作下一轮讨论。
|
||
|
||
长期成员不等于永久运行的模型进程。空闲时保留身份、任务和上下文索引，需要工作时再恢复执行。
|
||
|
||
## 4. 项目入职
|
||
|
||
项目详情增加「团队」，用户选择岗位后安排：
|
||
|
||
1. 负责范围：业务领域、模块、客户群体或明确产物。
|
||
2. 参考资料：项目概况、相关资料、工作目录和已有任务。
|
||
3. 协作与验收：向谁交付、依赖哪些成员、由谁验收。
|
||
4. 接任务方式：人工分配，或自动承接归属明确的任务。
|
||
|
||
建议入职后进行一次有边界的熟悉工作：读取相关概况与任务，按需检索资料，形成职责理解、可承接任务和待澄清问题。不一次性装入整个仓库、全部资料或所有聊天历史。
|
||
|
||
入职本身不授权执行所有未完成任务。自动执行依据用户设置的工作范围、接任务方式和操作权限；存在歧义时提出建议，避免自行扩大业务目标。
|
||
|
||
## 5. 任务分配与自动推进
|
||
|
||
复用现有任务状态：「待办／进行中／阻塞／待验收／已完成／已取消」。负责人和自动调度是新增能力，不能以已有任务状态代替实际运行。
|
||
|
||
建议每个任务有一个主要负责人，可有多个协作成员。确定交付责任后，由宿主原子领取和排队，防止重复领取或重复执行。用户调整任务仍使用版本校验，Agent 不能覆盖较新的人工修改。
|
||
|
||
工作循环：
|
||
|
||
```text
|
||
任务新增 / 依赖解除 / 收到协作消息
|
||
→ 检查负责范围、前置条件、暂停状态与执行额度
|
||
→ 明确归属的任务领取并排队
|
||
→ 执行、记录进展、验证、提交验收
|
||
→ 通过后完成；需要修改时继续原任务
|
||
```
|
||
|
||
- 归属不清或多人范围重叠：提出分工建议，不让多个成员竞相处理。
|
||
- 任务拆解：围绕已有目标，明确子任务的范围和验收；不按每条工具调用建任务。
|
||
- 缺少信息：记录阻塞原因和解除条件，向对应成员或用户提问。
|
||
- 任务等待期间：释放运行占用，可处理其他已具备条件的任务；避免反复请求模型询问进度。
|
||
- 完成判定：保留交付结果、验证依据和未验证项，遵守子任务与依赖检查。回复结束不是任务完成。
|
||
- 用量控制：并发、轮次和预算由宿主执行；具体默认值另行确定，不在本稿直接扩大现有并发。
|
||
|
||
自动推进由事件触发，事件需要去重和可恢复的工作状态。首版建议以应用运行期间为边界，最小化继续运行。退出应用后的持续执行需要单独的后台服务，不属于现有能力。重启可检查待办队列，但结果不确定的中断操作不能直接重放。
|
||
|
||
## 6. 多轮协作、上下文与交付
|
||
|
||
成员使用既有协作消息处理请求、补充、提问、回复、结果和通知，以稳定关系和 replyTo 追踪往来，不为每次回复新建成员。消息处理与任务领取需关联去重，避免一项工作同时经消息和任务触发两次。
|
||
|
||
任务记录责任、依赖和验收；消息记录交流；执行对话保留完整过程。三者相互关联，不以聊天正文解析结果直接替代任务事实。
|
||
|
||
成员可调用临时子 Agent，委派范围不能超过成员当前任务范围；结果由原负责人核对。角色说明、协作消息和子 Agent 自报身份均不能扩大权限或代替用户授权。
|
||
|
||
建议成员保留职责、经确认的项目知识和任务索引，具体任务使用可多轮继续的执行对话，避免所有工作永久堆入一个无限增长的聊天。资料采用已有项目范围及版本机制，运行时冻结引用，后续撤销仍优先；待定判断不得写成已确认事实。
|
||
|
||
通用业务示例：渠道拓展记录客户需求及来源 → 建立需求任务 → 开发成员澄清并拆解 → 实现和验收 → 售后准备说明并跟进。销售、售后使用各自的技能、连接器和交付条件，不强制依赖代码目录。对外发送、发布和退款等操作依照明确授权范围执行。
|
||
|
||
## 7. 职责边界与越界处理（首期采用规则隔离）
|
||
|
||
### 7.1 统一岗位、入职与任务规则
|
||
|
||
首期以明确规则引导 Agent 分工，配合任务依赖、协作交接与交付检查。暂不接入操作系统沙盒，也不以完成命令隔离研究作为岗位功能的启动条件。规则隔离属于行为约束，不能保证任意 Shell 或脚本在系统层面无法越界；已有授权、项目范围校验和连接器确认继续适用。
|
||
|
||
建议由宿主从岗位模板、项目入职安排和当前任务组装一份范围说明，在执行对话开始、恢复、上下文压缩后以及新回合使用有效版本；稳定职责保持稳定，不反复塞入全部历史。规则至少包含：
|
||
|
||
- 负责什么：业务领域、模块、客户范围和交付结果。
|
||
- 可以参考什么：资料、交付约定和相关目录；可以读取不代表可以修改。
|
||
- 可以修改或创建什么：明确目录、文件或业务对象，必要时列出例外。
|
||
- 不负责什么：禁止代做的其他岗位职责与操作。
|
||
- 依赖谁：前置交付、协作对象和解除阻塞的条件。
|
||
- 怎样完成：可核对的产物、验证方式和验收人。
|
||
|
||
实际范围由岗位、项目入职安排、本次任务和用户授权共同约束，不能简单相加。成员按范围领取与拆解任务；范围缺失、冲突或归属不清时澄清，不能默认获得整个项目的职责。检查与执行共用当前上下文，不为每次工具调用额外启动一次模型审查。
|
||
|
||
新文件按创建位置和用途判断是否属于本岗位工作，不采用“只要是自己创建就永久归自己”的规则。公共类型、共享配置和锁文件应明确负责人或修改约定，不能因为编译报错就顺手修改其他成员负责的内容。业务负责范围与工具操作授权分开：配置连接器不等于拥有全部账号操作权限；普通操作确认也不默认扩大职责。
|
||
|
||
Agent 不得通过改任务负责人、创建子任务、切换模型或调用另一种工具扩大范围。临时子 Agent 继承原成员的限制，再叠加本次委派范围；平级岗位之间发送请求时，接收方仍按自己的职责和任务条件判断。协作消息、技能或文件中的文字均不能自动扩大职责。允许跨范围时，由用户明确调整具体范围并记录版本；已有能力快照仍遵守回合边界约定，撤销不能仅靠下一次提示词提醒。
|
||
|
||
### 7.2 任务依赖与交接
|
||
|
||
任务依据实际工作需要配置依赖和交付条件，不预设岗位类型、固定工作阶段或执行顺序。
|
||
|
||
成员可以独立交付已满足条件的工作；依赖尚未满足的部分保持等待，并记录所需交付和负责成员。等待期间可处理其他职责范围内、具备执行条件的任务，不能代做依赖方的工作。
|
||
|
||
交接至少要说明需要什么、由谁交付、产物或版本在哪里、如何验证、何时满足条件。收到“已完成”的消息不等于自动证明依赖可用；核对交付后才能解除对应阻塞。交付不符合约定时反馈给负责人，约定变化时通知受影响的任务与成员。
|
||
|
||
### 7.3 通用越界流程
|
||
|
||
```text
|
||
发现范围外问题
|
||
→ 记录事实、影响与所需协助
|
||
→ 发送给负责成员，关联任务与约定
|
||
→ 需要等待的部分记录阻塞；可独立部分继续
|
||
→ 收到可核对交付，检查解除条件
|
||
→ 恢复原任务
|
||
```
|
||
|
||
没有负责人、范围冲突或需要扩大范围时交给用户决定。首版不额外设计多级审批组织；是否允许指定协调成员处理部分分工，后续再讨论。
|
||
|
||
若执行后才发现越界，停止继续扩大改动，报告具体文件或对象、影响与交接建议。不得擅自回退其他成员或用户的修改，也不因为测试通过就隐去越界事实。提交验收时汇总实际改动、验证证据、依赖与未完成项；代码项目可结合 diff 检查，非代码工作按实际交付和操作记录核对。
|
||
|
||
### 7.4 首期范围与后续增强
|
||
|
||
| 层次 | 首期建议 | 能力边界 |
|
||
|---|---|---|
|
||
| 任务元数据 | 负责人、依赖、版本及领取条件由宿主校验 | 职责描述仍需 Agent 理解，不能用关键词匹配证明归属 |
|
||
| 文件读写 | 将参考范围和可修改范围写入执行规则 | 不宣称已在文件系统层强制拦截 |
|
||
| Shell / 脚本 | 命令的预期副作用也须遵守相同范围规则 | 不增加脆弱的命令字符串黑名单，不宣称沙盒隔离 |
|
||
| 连接器 | 规则描述业务对象与允许行为，保留已有确认 | 岗位规则不自动扩展服务端账号权限 |
|
||
| 交付 | 核对实际改动、结果、验证和依赖 | 事后检查可以发现问题，不能防止已发生的副作用 |
|
||
|
||
首期不新增独立权限语言、通用审批引擎或强制每个岗位使用独立工作副本。使用当前任务、消息、对话和授权机制完成分工闭环，并记录发生过的越界与交接问题，作为后续改进依据。
|
||
|
||
后续如果需要系统层强制限制，再对文件、命令、子进程和宿主连接器逐项选择并验证隔离方式。普通 worktree 与规则字段本身都不构成安全边界；沙盒技术选型暂缓。
|
||
|
||
## 8. 页面与操作建议
|
||
|
||
- 全局入口改为「岗位 · 技能 · 连接器」；岗位页用于创建、配置、复制与停用。
|
||
- 项目详情增加「团队」，展示成员、负责范围、当前任务与真实状态。
|
||
- 入职以渐进表单安排职责、资料、模型和接任务方式，不塞入执行层术语。
|
||
- 任务列表及看板增加负责人和筛选；任务详情展示交接条件、依赖和阻塞原因。
|
||
- 成员详情可以发要求、看任务与往来、暂停接任务、打开执行对话。
|
||
- 执行对话复用现有流式、工具、授权、问题回答和工作台；不另造一套执行界面。
|
||
- 范围外请求明确展示“需要谁处理”和影响；缺少职责配置时引导补齐，避免静默失败。
|
||
|
||
界面沿用现有六档字体和布局语言，具体交互待功能边界确定后设计；真实桌面验收要求仍按项目约束执行。
|
||
|
||
## 9. 当前基础与待实现能力
|
||
|
||
截至本稿，已核对现有代码与进度文档：
|
||
|
||
| 能力 | 现状 |
|
||
|---|---|
|
||
| 技能、连接器、回合快照 | 已有基础，具体支持范围以原进度文档为准 |
|
||
| 项目任务、依赖、历史、验收字段 | 已实现；首版补充成员负责人和明确条件自动承接 |
|
||
| 多轮子 Agent / 对话协作、排队、因果关联 | OMP 已实现；首版项目团队复用其多轮、队列与等待机制 |
|
||
| 原专家入口 | 已改为岗位，支持真实职责、技能和模型配置 |
|
||
| 岗位、项目成员、入职 | OMP 首版已接入；每成员持久执行对话 |
|
||
| 任务负责人、领取、事件驱动承接 | 明确分配、自动承接开关、依赖与子任务检查、持久队列已接入；不支持智能抢单 |
|
||
| 岗位职责、任务范围与交接规则 | 每回合注入职责规则，子 Agent 继承；任务字段及人工验收由宿主校验，非沙盒 |
|
||
| 文件、Shell 等强制隔离 | 后续选项，首期暂不接入 |
|
||
| 应用退出后的持续工作 | 尚无后台服务 |
|
||
|
||
复用现有任务、消息、对话和能力机制。角色与调度合同由宿主管理，首期验证现有 OMP；其他基座另行适配。首版数据库表、IPC 与工具参数见[进度及 SOP](ygent-team-integration.md)，不增加第二套聊天内核或通用工作流框架。
|
||
|
||
## 10. 建议实施顺序与验收
|
||
|
||
以下为整体演进顺序；用户已授权并实施最小闭环，未落地能力及尚未验证的场景以进度及 SOP 为准：
|
||
|
||
1. 定清岗位、项目入职和任务规则的组合、继承、变更与越界交接方式。
|
||
2. 岗位定义、模型与能力配置、项目入职和成员身份持久化。
|
||
3. 任务负责人、领取、依赖交接和成员多轮协作。
|
||
4. 在明确的职责和任务条件内加入事件触发、队列、暂停、预算与中断恢复。
|
||
5. 使用职责不同的岗位跑通跨岗位协作闭环，验收覆盖代码与非代码工作，不绑定具体岗位组合。
|
||
|
||
首个完整闭环：创建岗位 → 项目入职 → 指定范围 → 承接明确任务 → 协作和等待依赖 → 实际验证 → 提交验收。
|
||
|
||
关键验收场景：
|
||
|
||
- 同一岗位加入两个项目，资料、任务、cwd 和授权不串线。
|
||
- 岗位使用实际配置的模型；配置变更在正确回合生效。
|
||
- 成员完成职责内交付后不代做依赖方的工作；依赖经核对满足条件后，才恢复对应任务。
|
||
- 两个成员不会重复领取；忙碌、暂停、重复事件不会重复执行。
|
||
- 跨岗位问题可多轮澄清，交接保持任务与消息来源。
|
||
- 普通执行、恢复对话、上下文压缩和子 Agent 委派均保留有效范围规则；协作消息不改变职责。
|
||
- 对范围外文件修改、命令副作用、连接器操作及职责外代做的测试请求，成员按规则交接；记录实际表现，不把行为测试通过等同于系统层强制隔离。
|
||
- 共享资源职责冲突、撤销范围、交付约定变化均有可见处理结果。
|
||
- 取消、异常退出和重启不把未知结果当成成功，也不重复外部操作。
|
||
- UI 状态来自真实队列和运行；空闲成员不会为了显示在线而持续调用模型。
|
||
|
||
## 11. 下一轮待讨论
|
||
|
||
1. 规则配置如何保持简单：业务描述、参考范围、修改范围和依赖如何安排？
|
||
2. 首版由用户明确分配、自动承接默认关闭；后续是否支持范围重叠时的协调分配？
|
||
3. 哪类任务允许依据检查自动验收，哪类必须人工验收？
|
||
4. 共享资源的责任归属和任务重分配如何处理？
|
||
5. 模型覆盖、岗位模板升级、成员长期上下文如何管理？
|
||
6. 规则变更、上下文恢复和长期成员如何同步有效职责，避免旧规则继续影响任务？
|
||
7. 实际用量如何计费展示与限额，预算耗尽后如何恢复？
|
||
|
||
讨论后在对应章节原地修订，记录已确定结论和仍待决定的问题，避免把建议自动升级成项目约束。
|
||
|
||
## 12. 文档维护与关联资料
|
||
|
||
本文件作为持续讨论的源文件，以文件来源接入「ygent 项目 → 资料库 → 资料」。后续修改同一路径，由资料库刷新生成新版本；必要时手动刷新。修改文件不会直接替换已开始回合冻结的旧版本，已删除或撤销资料仍按现有规则处理。
|
||
|
||
只关联这一份方案文件，不因此登记整个工作目录。资料库条目 ID 与版本属于本机用户数据，不写入仓库。本文进入项目资料库供讨论引用，不额外写成“已确认”的项目记忆。
|
||
|
||
- [原专家、技能、连接器方案](ygent-capability-integration-plan.md)：技能与连接器基础继续复用，岗位首版与后续方向见本文及进度 SOP。
|
||
- [协作方案](ygent-collaboration-plan.md)与[实际进度](ygent-collaboration-progress.md)：多轮消息、运行与恢复边界。
|
||
- [项目任务方案](ygent-project-tasks.md)：任务状态、验收、版本与宿主工具。
|
||
- [资料库方案](ygent-library-plan.md)与[接入进度](ygent-library-integration.md)：归属、来源与版本规则。
|
||
|
||
修订记录：
|
||
|
||
- 2026-10-10，v0.1，整理岗位与项目团队整体方向，补充职责边界和交接规则，标明执行隔离等未决项；仅交付文档。
|
||
- 2026-10-11，v0.2，按用户选择改为首期规则隔离，补充范围组合、新文件归属、子 Agent 继承和越界交接；移除沙盒作为首期前置条件，同步实施顺序与验收边界。仅更新方案，功能尚未实现。
|
||
- 2026-10-11，v0.3，移除具体岗位分工示例，将目标、依赖交接、实施顺序和验收项统一为通用规则，不将讨论中的例子固化为产品流程。
|
||
|
||
- 2026-10-11，v0.4，按用户授权实施 OMP 最小闭环：岗位配置、项目入职、职责规则、明确任务自动承接、多轮协作和人工验收；关联实际进度与原生验收 SOP，保留尚未接入的长期建议。
|
||
|
||
- 2026-10-11，v0.5，按用户要求增加默认项目经理、入职职责审核与任务分配；经理只读协调、普通成员审核通过后执行，最终用户验收。具体交付和证据以进度 SOP 为准。
|
||
|
||
- 2026-10-11，v0.6，增加普通项目对话向既有岗位成员发要求、持续多轮返回；岗位编辑直接取消，统一模型选择面板；经理配置项目独立且不可删除/禁用。
|
||
|
||
## 已落地补充：经理自主组队
|
||
|
||
项目经理可以按用户明确需求复用现有岗位或创建项目专用岗位，办理入职、审核职责范围、分配完整任务并协调交付。新建岗位默认继承经理模型和推理配置，可调整；经理创建成员默认开启自动承接，但审核、范围、验收条件及依赖仍是执行前提。项目岗位只属于本项目，只有用户显式操作才能复制为全局岗位。经理不能扩大自身执行权限或代用户验收。具体工具、界面、边界与本机验收证据见[实施进度及 SOP](ygent-team-integration.md#经理自主组队2026-10-11)。
|
||
|
||
|
||
## 当前执行阶段：入职审核与任务规划
|
||
|
||
按最新约定，员工暂不执行。入职审核后，经理必须查看现有任务，根据当前岗位和负责范围复用、调整或拆分，明确任务负责人、依赖及验收，再提交完整当前版本规划。规划完成只代表分工确认，不代表开始执行；后续开放执行需单独确定，不加入本轮。
|
||
|
||
岗位职责或成员范围变化使规划重新待办。经理未完成规划时可显式重试，不由员工主动接任务补齐流程。具体实现与验收见[进度及 SOP](ygent-team-integration.md#入职后任务规划与执行暂停2026-10-11)。
|
||
|
||
- 2026-10-11，v0.7，增加持久任务规划阶段及完整版本提交；本轮员工执行全局保持暂停，覆盖先前自动执行约定。
|
||
|
||
|
||
- 2026-10-11，v0.8，补充经理移除空闲项目成员工具；先交接未结束任务，保留文件和对话历史，移除使规划失效，退出身份不可继续执行，经理不可移除。见岗位进度 SOP。
|