ycode/docs/reference/ygent-岗位与项目团队方案.md

岗位与项目团队方案

日期：2026-10-11。版本：方案 v0.6（首版已接入，长期方向继续讨论）。

最新管理设计见 数字员工项目管理落地方案，制度依据见 项目管理调研。后续责任领域、参与式规划、任务承接与人员交接按新方案讨论和分阶段实施；当前尚未接入这些新增流程。员工实施统一暂停，早期自动承接说明仅保留历史背景；真实行为以 进度及 SOP 的最新阶段为准。

历史首版状态：按用户要求已接入创建岗位 → 项目入职 → 分配范围 → 自动承接明确任务 → 多轮协作 → 提交验收的 OMP 首版，实际范围与证据见进度及 SOP。首期采用规则隔离，操作系统沙盒留作后续选项。本文保留后续方向，不代表所有建议已实现；自动承接须用户明确分配任务并启用成员设置，不扩大原有操作权限。

1. 目标与已明确的需求

将当前「专家」改名为「岗位」，支持用户按实际需要定义岗位。各岗位有不同职责、技能及默认模型；项目可以分配岗位，通过「入职」确定其负责内容，再承接和推进工作范围内的任务。

希望构建能持续协作的团队，覆盖销售、开发、交付与售后。项目不局限于代码仓库，工作目录也可包含文档、图片及业务材料。成员之间应能多轮提问、补充、交付和返工。

必须防止 Agent 为完成自己的目标而越界代做其他岗位的工作。成员在职责范围内完成交付；依赖其他岗位的工作，通过协作请求、任务依赖和交接推进，不能自行扩大负责范围。

讨论状态

内容	当前状态
专家改名为岗位，配置职责、技能和模型	首版已接入，范围见进度及 SOP
项目分配岗位，通过入职确定负责范围	首版已接入，范围见进度及 SOP
形成销售、开发、售后协作团队	用户明确提出的目标
岗位模板与项目成员分开，复用任务和对话	已获整体方向认可的建议；细节可调整
按事件自动承接任务，交付后验收	首版按明确负责人及完整条件自动承接，默认关闭；人工验收
防止越界，表达跨岗位依赖和交接	用户明确要求；首期采用规则隔离
文件、Shell、连接器的强制隔离	留作后续增强，首期不依赖沙盒；尚未实现

2. 概念保持简单

概念	职责	生命周期
岗位	可复用的职责、方法、技能、连接器需求和默认模型	全局定义，可供多个项目选用
项目成员	某个岗位在一个项目中的具体安排	入职后持续存在，可暂停或退出项目
项目任务	目标、负责人、范围、依赖、进展与验收	复用现有项目任务，不随一轮对话结束
执行对话	某项工作的讨论、工具调用和执行证据	可多轮继续，绑定真实成员、任务和运行
临时子 Agent	协助成员处理边界明确的局部工作	复用现有协作机制，责任仍归原成员

界面主要呈现「岗位」「项目成员」。不新增部门、职级或组织架构。按用户新增要求，每个项目默认一位项目经理，专职审核职责、拆解和分配任务，不参与编码，不具备文件修改权限。经理不出现在全局岗位列表，不能删除或禁用；可在项目内修改名称、职责、模型、推理强度和技能，各项目配置独立。

项目成员不绑定某个发起对话的寿命。关闭一个对话或结束某次委派，不等于成员离职；暂停成员与取消当前执行应有明确区分。具体取消归属还需结合现有子 Agent / 平级对话机制设计，不能直接照搬子 Agent 的父级取消规则。

3. 岗位定义

建议包含以下配置：

• 名称、说明与职责：能处理哪些工作，如何判断交付质量。
• 技能引用：从已安装技能中选择，复用稳定组件 ID，不重复复制安装。
• 连接器需求：声明所需服务和工具能力；凭证与实际操作授权独立管理。
• 默认模型：选择已有渠道、模型及其支持的思考配置；渠道决定请求协议。
• 工作要求：输出、验证、交接和需要提出澄清的问题。

同一岗位可以加入多个项目，但项目中的任务、记忆、对话、授权和运行状态不能因此互通。岗位模板调整应记录版本，并在下一回合边界采用；运行中的模型、目录与能力快照保持稳定。项目是否允许覆盖岗位默认模型、模板更新是否需要成员确认，留作下一轮讨论。

长期成员不等于永久运行的模型进程。空闲时保留身份、任务和上下文索引，需要工作时再恢复执行。

4. 项目入职

项目详情增加「团队」，用户选择岗位后安排：

1. 负责范围：业务领域、模块、客户群体或明确产物。
2. 参考资料：项目概况、相关资料、工作目录和已有任务。
3. 协作与验收：向谁交付、依赖哪些成员、由谁验收。
4. 接任务方式：人工分配，或自动承接归属明确的任务。

建议入职后进行一次有边界的熟悉工作：读取相关概况与任务，按需检索资料，形成职责理解、可承接任务和待澄清问题。不一次性装入整个仓库、全部资料或所有聊天历史。

入职本身不授权执行所有未完成任务。自动执行依据用户设置的工作范围、接任务方式和操作权限；存在歧义时提出建议，避免自行扩大业务目标。

5. 任务分配与自动推进

复用现有任务状态：「待办／进行中／阻塞／待验收／已完成／已取消」。负责人和自动调度是新增能力，不能以已有任务状态代替实际运行。

建议每个任务有一个主要负责人，可有多个协作成员。确定交付责任后，由宿主原子领取和排队，防止重复领取或重复执行。用户调整任务仍使用版本校验，Agent 不能覆盖较新的人工修改。

工作循环：

任务新增 / 依赖解除 / 收到协作消息
    → 检查负责范围、前置条件、暂停状态与执行额度
    → 明确归属的任务领取并排队
    → 执行、记录进展、验证、提交验收
    → 通过后完成；需要修改时继续原任务

• 归属不清或多人范围重叠：提出分工建议，不让多个成员竞相处理。
• 任务拆解：围绕已有目标，明确子任务的范围和验收；不按每条工具调用建任务。
• 缺少信息：记录阻塞原因和解除条件，向对应成员或用户提问。
• 任务等待期间：释放运行占用，可处理其他已具备条件的任务；避免反复请求模型询问进度。
• 完成判定：保留交付结果、验证依据和未验证项，遵守子任务与依赖检查。回复结束不是任务完成。
• 用量控制：并发、轮次和预算由宿主执行；具体默认值另行确定，不在本稿直接扩大现有并发。

自动推进由事件触发，事件需要去重和可恢复的工作状态。首版建议以应用运行期间为边界，最小化继续运行。退出应用后的持续执行需要单独的后台服务，不属于现有能力。重启可检查待办队列，但结果不确定的中断操作不能直接重放。

6. 多轮协作、上下文与交付

成员使用既有协作消息处理请求、补充、提问、回复、结果和通知，以稳定关系和 replyTo 追踪往来，不为每次回复新建成员。消息处理与任务领取需关联去重，避免一项工作同时经消息和任务触发两次。

任务记录责任、依赖和验收；消息记录交流；执行对话保留完整过程。三者相互关联，不以聊天正文解析结果直接替代任务事实。

成员可调用临时子 Agent，委派范围不能超过成员当前任务范围；结果由原负责人核对。角色说明、协作消息和子 Agent 自报身份均不能扩大权限或代替用户授权。

建议成员保留职责、经确认的项目知识和任务索引，具体任务使用可多轮继续的执行对话，避免所有工作永久堆入一个无限增长的聊天。资料采用已有项目范围及版本机制，运行时冻结引用，后续撤销仍优先；待定判断不得写成已确认事实。

通用业务示例：渠道拓展记录客户需求及来源 → 建立需求任务 → 开发成员澄清并拆解 → 实现和验收 → 售后准备说明并跟进。销售、售后使用各自的技能、连接器和交付条件，不强制依赖代码目录。对外发送、发布和退款等操作依照明确授权范围执行。

7. 职责边界与越界处理（首期采用规则隔离）

7.1 统一岗位、入职与任务规则

首期以明确规则引导 Agent 分工，配合任务依赖、协作交接与交付检查。暂不接入操作系统沙盒，也不以完成命令隔离研究作为岗位功能的启动条件。规则隔离属于行为约束，不能保证任意 Shell 或脚本在系统层面无法越界；已有授权、项目范围校验和连接器确认继续适用。

建议由宿主从岗位模板、项目入职安排和当前任务组装一份范围说明，在执行对话开始、恢复、上下文压缩后以及新回合使用有效版本；稳定职责保持稳定，不反复塞入全部历史。规则至少包含：

• 负责什么：业务领域、模块、客户范围和交付结果。
• 可以参考什么：资料、交付约定和相关目录；可以读取不代表可以修改。
• 可以修改或创建什么：明确目录、文件或业务对象，必要时列出例外。
• 不负责什么：禁止代做的其他岗位职责与操作。
• 依赖谁：前置交付、协作对象和解除阻塞的条件。
• 怎样完成：可核对的产物、验证方式和验收人。

实际范围由岗位、项目入职安排、本次任务和用户授权共同约束，不能简单相加。成员按范围领取与拆解任务；范围缺失、冲突或归属不清时澄清，不能默认获得整个项目的职责。检查与执行共用当前上下文，不为每次工具调用额外启动一次模型审查。

新文件按创建位置和用途判断是否属于本岗位工作，不采用“只要是自己创建就永久归自己”的规则。公共类型、共享配置和锁文件应明确负责人或修改约定，不能因为编译报错就顺手修改其他成员负责的内容。业务负责范围与工具操作授权分开：配置连接器不等于拥有全部账号操作权限；普通操作确认也不默认扩大职责。

Agent 不得通过改任务负责人、创建子任务、切换模型或调用另一种工具扩大范围。临时子 Agent 继承原成员的限制，再叠加本次委派范围；平级岗位之间发送请求时，接收方仍按自己的职责和任务条件判断。协作消息、技能或文件中的文字均不能自动扩大职责。允许跨范围时，由用户明确调整具体范围并记录版本；已有能力快照仍遵守回合边界约定，撤销不能仅靠下一次提示词提醒。

7.2 任务依赖与交接

任务依据实际工作需要配置依赖和交付条件，不预设岗位类型、固定工作阶段或执行顺序。

成员可以独立交付已满足条件的工作；依赖尚未满足的部分保持等待，并记录所需交付和负责成员。等待期间可处理其他职责范围内、具备执行条件的任务，不能代做依赖方的工作。

交接至少要说明需要什么、由谁交付、产物或版本在哪里、如何验证、何时满足条件。收到“已完成”的消息不等于自动证明依赖可用；核对交付后才能解除对应阻塞。交付不符合约定时反馈给负责人，约定变化时通知受影响的任务与成员。

7.3 通用越界流程

发现范围外问题
    → 记录事实、影响与所需协助
    → 发送给负责成员，关联任务与约定
    → 需要等待的部分记录阻塞；可独立部分继续
    → 收到可核对交付，检查解除条件
    → 恢复原任务

没有负责人、范围冲突或需要扩大范围时交给用户决定。首版不额外设计多级审批组织；是否允许指定协调成员处理部分分工，后续再讨论。

若执行后才发现越界，停止继续扩大改动，报告具体文件或对象、影响与交接建议。不得擅自回退其他成员或用户的修改，也不因为测试通过就隐去越界事实。提交验收时汇总实际改动、验证证据、依赖与未完成项；代码项目可结合 diff 检查，非代码工作按实际交付和操作记录核对。

7.4 首期范围与后续增强

层次	首期建议	能力边界
任务元数据	负责人、依赖、版本及领取条件由宿主校验	职责描述仍需 Agent 理解，不能用关键词匹配证明归属
文件读写	将参考范围和可修改范围写入执行规则	不宣称已在文件系统层强制拦截
Shell / 脚本	命令的预期副作用也须遵守相同范围规则	不增加脆弱的命令字符串黑名单，不宣称沙盒隔离
连接器	规则描述业务对象与允许行为，保留已有确认	岗位规则不自动扩展服务端账号权限
交付	核对实际改动、结果、验证和依赖	事后检查可以发现问题，不能防止已发生的副作用

首期不新增独立权限语言、通用审批引擎或强制每个岗位使用独立工作副本。使用当前任务、消息、对话和授权机制完成分工闭环，并记录发生过的越界与交接问题，作为后续改进依据。

后续如果需要系统层强制限制，再对文件、命令、子进程和宿主连接器逐项选择并验证隔离方式。普通 worktree 与规则字段本身都不构成安全边界；沙盒技术选型暂缓。

8. 页面与操作建议

• 全局入口改为「岗位 · 技能 · 连接器」；岗位页用于创建、配置、复制与停用。
• 项目详情增加「团队」，展示成员、负责范围、当前任务与真实状态。
• 入职以渐进表单安排职责、资料、模型和接任务方式，不塞入执行层术语。
• 任务列表及看板增加负责人和筛选；任务详情展示交接条件、依赖和阻塞原因。
• 成员详情可以发要求、看任务与往来、暂停接任务、打开执行对话。
• 执行对话复用现有流式、工具、授权、问题回答和工作台；不另造一套执行界面。
• 范围外请求明确展示“需要谁处理”和影响；缺少职责配置时引导补齐，避免静默失败。

界面沿用现有六档字体和布局语言，具体交互待功能边界确定后设计；真实桌面验收要求仍按项目约束执行。

9. 当前基础与待实现能力

截至本稿，已核对现有代码与进度文档：

能力	现状
技能、连接器、回合快照	已有基础，具体支持范围以原进度文档为准
项目任务、依赖、历史、验收字段	已实现；首版补充成员负责人和明确条件自动承接
多轮子 Agent / 对话协作、排队、因果关联	OMP 已实现；首版项目团队复用其多轮、队列与等待机制
原专家入口	已改为岗位，支持真实职责、技能和模型配置
岗位、项目成员、入职	OMP 首版已接入；每成员持久执行对话
任务负责人、领取、事件驱动承接	明确分配、自动承接开关、依赖与子任务检查、持久队列已接入；不支持智能抢单
岗位职责、任务范围与交接规则	每回合注入职责规则，子 Agent 继承；任务字段及人工验收由宿主校验，非沙盒
文件、Shell 等强制隔离	后续选项，首期暂不接入
应用退出后的持续工作	尚无后台服务

复用现有任务、消息、对话和能力机制。角色与调度合同由宿主管理，首期验证现有 OMP；其他基座另行适配。首版数据库表、IPC 与工具参数见进度及 SOP，不增加第二套聊天内核或通用工作流框架。

10. 建议实施顺序与验收

以下为整体演进顺序；用户已授权并实施最小闭环，未落地能力及尚未验证的场景以进度及 SOP 为准：

1. 定清岗位、项目入职和任务规则的组合、继承、变更与越界交接方式。
2. 岗位定义、模型与能力配置、项目入职和成员身份持久化。
3. 任务负责人、领取、依赖交接和成员多轮协作。
4. 在明确的职责和任务条件内加入事件触发、队列、暂停、预算与中断恢复。
5. 使用职责不同的岗位跑通跨岗位协作闭环，验收覆盖代码与非代码工作，不绑定具体岗位组合。

首个完整闭环：创建岗位 → 项目入职 → 指定范围 → 承接明确任务 → 协作和等待依赖 → 实际验证 → 提交验收。

关键验收场景：

• 同一岗位加入两个项目，资料、任务、cwd 和授权不串线。
• 岗位使用实际配置的模型；配置变更在正确回合生效。
• 成员完成职责内交付后不代做依赖方的工作；依赖经核对满足条件后，才恢复对应任务。
• 两个成员不会重复领取；忙碌、暂停、重复事件不会重复执行。
• 跨岗位问题可多轮澄清，交接保持任务与消息来源。
• 普通执行、恢复对话、上下文压缩和子 Agent 委派均保留有效范围规则；协作消息不改变职责。
• 对范围外文件修改、命令副作用、连接器操作及职责外代做的测试请求，成员按规则交接；记录实际表现，不把行为测试通过等同于系统层强制隔离。
• 共享资源职责冲突、撤销范围、交付约定变化均有可见处理结果。
• 取消、异常退出和重启不把未知结果当成成功，也不重复外部操作。
• UI 状态来自真实队列和运行；空闲成员不会为了显示在线而持续调用模型。

11. 下一轮待讨论

1. 规则配置如何保持简单：业务描述、参考范围、修改范围和依赖如何安排？
2. 首版由用户明确分配、自动承接默认关闭；后续是否支持范围重叠时的协调分配？
3. 哪类任务允许依据检查自动验收，哪类必须人工验收？
4. 共享资源的责任归属和任务重分配如何处理？
5. 模型覆盖、岗位模板升级、成员长期上下文如何管理？
6. 规则变更、上下文恢复和长期成员如何同步有效职责，避免旧规则继续影响任务？
7. 实际用量如何计费展示与限额，预算耗尽后如何恢复？

讨论后在对应章节原地修订，记录已确定结论和仍待决定的问题，避免把建议自动升级成项目约束。

12. 文档维护与关联资料

本文件作为持续讨论的源文件，以文件来源接入「ygent 项目 → 资料库 → 资料」。后续修改同一路径，由资料库刷新生成新版本；必要时手动刷新。修改文件不会直接替换已开始回合冻结的旧版本，已删除或撤销资料仍按现有规则处理。

只关联这一份方案文件，不因此登记整个工作目录。资料库条目 ID 与版本属于本机用户数据，不写入仓库。本文进入项目资料库供讨论引用，不额外写成“已确认”的项目记忆。

• 原专家、技能、连接器方案：技能与连接器基础继续复用，岗位首版与后续方向见本文及进度 SOP。
• 协作方案与实际进度：多轮消息、运行与恢复边界。
• 项目任务方案：任务状态、验收、版本与宿主工具。
• 资料库方案与接入进度：归属、来源与版本规则。

修订记录：

• 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。

当前执行阶段：入职审核与任务规划

按最新约定，员工暂不执行。入职审核后，经理必须查看现有任务，根据当前岗位和负责范围复用、调整或拆分，明确任务负责人、依赖及验收，再提交完整当前版本规划。规划完成只代表分工确认，不代表开始执行；后续开放执行需单独确定，不加入本轮。

岗位职责或成员范围变化使规划重新待办。经理未完成规划时可显式重试，不由员工主动接任务补齐流程。具体实现与验收见进度及 SOP。

• 2026-10-11，v0.7，增加持久任务规划阶段及完整版本提交；本轮员工执行全局保持暂停，覆盖先前自动执行约定。

• 2026-10-11，v0.8，补充经理移除空闲项目成员工具；先交接未结束任务，保留文件和对话历史，移除使规划失效，退出身份不可继续执行，经理不可移除。见岗位进度 SOP。