企业官网建设流程全解析

• 人工智能
• AI 应用
• 开发工具
• CLI
• AI Agent
• dsh-plugin
• DeepSeek

本文以 ccg-workflow 仓库中 多 Agent 协同秘典 为主体,完整拆解其多 Agent 协同的核心方法论:何时用团队、如何用 Codex 原生动作落地、如何按文件/模块/流水线拆分任务、如何用 SendMessage 与文件锁定避免并发写冲突,以及失败降级与结果汇总的完整闭环。结合 dsh-ccg 的 团队工具实现 与 文件所有权存储,你可以把文档中的"约定"对应到可执行的工程机制,掌握一套在多模型协作开发场景中可直接复用的并行调度方案。

一、启用条件:TeamCreate vs Task(subagent) 决策树

多 Agent 协同的第一课是"何时启用"。multi-agent.md 给出的决策树如下,这也是该秘典所属 协同编排知识域 的核心入口判断:

收到任务 → 评估规模 │ ├─ 涉及 ≥3 个独立文件/模块？ → TeamCreate ├─ 需要 ≥2 个并行工作流？ → TeamCreate ├─ 总步骤 >10 步？ → TeamCreate ├─ 魔尊明确要求并行/团队？ → TeamCreate │ ├─ 单一探索/搜索任务？ → Task(subagent_type=Explore) ├─ 单文件独立操作？ → Task(subagent) └─ 简单查询/单步操作？ → 直接执行

铁律:当犹豫时,优先 TeamCreate。多 Agent 并行效率远高于串行 subagent。

文档同时给出了量化决策矩阵——满足任意 1 条即启用 TeamCreate:

这套决策逻辑在 dsh-ccg 的 团队系统提示词 中被进一步工程化:团队只有在"工作真正可拆(独立模块/文件/关注点)、每部分足够分量、任务会持续发展"三个条件同时成立时才值得其成本;反例(单一问题、需要多方意见、必须按序执行)分别指向一次性角色工具、Panel 或顺序执行。可以推断,文档中"犹豫时优先 TeamCreate"的铁律针对的是任务规模判断,而源码补充的是"单次一次性委派更便宜"的反向边界,两者结合才是完整的启用判断。

二、Codex 原生动作映射:协同动作的落地工具表

文档明确了 TeamCreate/Task 抽象在 Codex CLI 中对应的原生工具:

执行顺序:锁文件 → 并行执行 → 审查修复 → 汇总 → 回收子 Agent。

同仓库中更详细的 天罗秘典 · 蚁群仿生版 给这张表补充了每个动作的约束列,值得对照使用:

并把执行顺序细化为不可跳步的五步:拆解任务+文件锁定矩阵 → spawn explorer/worker/awaiter → 并行执行+wait 收敛 → reviewer 审查+必要修复 → 汇总结果+close_agent 全量回收。

从源码结构看,dsh-ccg 插件在 DeepSeek 运行环境里实现了同构的"团队原语":hire 工具 负责"招聘"一个常驻队友(对应spawn_agent),系统提示词约定用send_message下发后续任务、report由队友主动回传结果、interrupt_agent中止跑偏的一轮、list_agents查看存活成员、close类动作回收。其中 formatHireReport 明确告诫协调者:队友的答案不会经由本次调用返回,"结束当前轮次就是等待"——这与决策树中"简单查询用一次性 subagent、长协作用团队"的分界完全一致:一次性子代理答一次即销毁,无法被后续追问,这正是团队的不可替代之处(参见 team.js 文件头注释)。

三、角色定义:Lead / Worker / Reviewer / Scout

文档定义了四角色体系(角色名"道侣/护法/斥候"为该秘典的"道语"命名):

蚁群仿生版秘典 把这套角色映射到蚁群生命周期(侦察→工作→审查→修复→完成),并补充了两个维度:

• 模型建议:斥候用低成本快速模型(haiku 类),道侣/护法用主力模型,主修用当前模型;
• 走卒 (Drone):只做短命令的 Bash-only 角色,零 LLM 成本,等价于"直接执行"。

角色使用时机:需要了解代码库结构 → 派 Scout;需要修改代码 → 派 Worker;需要审查变更 → 派 Soldier(审查模式);需要长耗时命令 → 派 awaiter;短命令 → 直接 Bash。

这些角色在 dsh-ccg 中有可直接对照的实现。roles.js 定义了六角色矩阵:analyzer(ccg_analyze)、architect(ccg_design)、builder(ccg_build)、debugger(ccg_debug)、optimizer(ccg_optimize)、reviewer(ccg_review)、tester(ccg_test),每个角色绑定独立的 persona 提示词与模型档位(tier:strong/worker)。例如 reviewer 的 persona 要求"READ-ONLY: comment, do not rewrite",发现按 Critical/Warning/Info 分级并锚定 file:line,与"护法 = 只读审查"的定义一致;builder 的 persona 要求"Stay inside the files you were asked to change",与下文道侣模板的"不触碰未分配文件"铁律同构。

四、任务分解策略:按文件(首选)/ 按模块 / 按流水线

文档给出三种拆分策略,顺序即优先级:

按文件拆分(首选)——每个 Agent 负责独立的文件集合,零交叉:

Agent-A: [file1.md, file2.md] — 互不干涉 Agent-B: [file3.md, file4.md] — 互不干涉 Agent-C: [file5.md] — 互不干涉

按模块拆分——每个 Agent 负责一个功能模块:

Agent-前端: src/components/ Agent-后端: src/api/ Agent-基础: src/lib/

按流水线拆分——串行依赖时,前一个 Agent 的输出是后一个的输入:

Agent-生成 → Agent-校验 → Agent-集成

蚁群仿生版 把流水线拆分管到统一生命周期Scout(侦察) → Worker(执行) → Soldier(审查) → Worker(修复) → Lead(汇总),并补充了依赖感知调度:文件 A import 文件 B 时,B 的任务必须先完成,A 标记 blocked;且"被更多文件依赖的底层模块优先处理"。

并行 vs 串行决策

子任务A和B是否共享文件？ ├─ 否 → 并行执行 └─ 是 → 是否写同一文件？ ├─ 否（一读一写）→ 先写后读，串行 └─ 是（都写）→ 严格串行，或拆分文件区域

文档用依赖矩阵示例说明调度结论:

结论:A 与 B 并行,C 等 B 完成后执行。

五、文件锁定与冲突避免:黄金规则及其机械化实现

文档约定

每个文件在同一时刻只能被一个Agent修改。 违反此规则 = 道基裂痕+1。

锁定策略三步:

1. 分配时锁定—— 主修分配任务时明确文件归属;
2. 声明式锁定—— 道侣开始前声明要操作的文件;
3. 冲突检测—— 主修检查文件分配无重叠后才启动。

冲突解决表:

源码纵深:从"约定"到"机制"

文档中的黄金规则在 dsh-ccg 中被实现为硬性机制,这是本文最值得对照阅读的部分。

1) owns 参数与冲突预检。hire 工具的参数定义 要求协调者为每个队友传入owns(独占可写的文件/目录,glob 支持),并写明"Give every concurrent teammate a disjoint set: two agents editing one file lose each other's work silently"。execute 流程 中的注释直白地点题:"Refuse BEFORE starting anything. One writer per file is this feature's central claim, and a check that ran after the child was already working would be a warning, not a rule"——冲突检查必须在子 Agent 启动之前拒绝,而不是启动后告警。

2) 路径归一化与碰撞判定。memory.js 提供了三个函数:

• normalisePath:统一分隔符、去掉./前缀与尾部/,保证src/a.js与./src/a.js视为同一文件;
• reachOf:计算 glob 的可达目录(src/*.js可达src),用于目录级碰撞;
• pathsCollide:判定两条所有权声明是否可能触碰同一文件,注释强调"Deliberately generous"——宁可误报(协调者换个文件分配),不可漏报(两个 Agent 静默互相覆盖)。

collisionsWith输出冲突对,describeCollisions 生成的错误信息会指名道姓:哪个角色(childId)持有哪些路径、你请求的哪条路径与之重叠,并给出两条出路——换文件,或send_message把活派给现有持有者,或先用 roster 工具的release动作收回文件。

3) 所有权持久化与失效回收。所有权记录不放在对话里,而是 存储到持久域ccg_team的teammates表(childId、hiredBy、workspace、role、owns、hiredAt 等字段),可跨压缩/重启存活。sweepStale 负责清除子 Agent 已不存在的"僵尸占用行",且带有 5 分钟宽限期 保护刚招聘(尚在创建窗口内、可能还未出现在存活列表里)的成员,避免误删;查询失败时保守保留所有行。此外 foreignClaimsIn 会把同一工作区里其他会话占用的文件以警告形式暴露出来(不阻止,因为那可能是已死会话)——这正好覆盖文档冲突表中"依赖文件未就绪"之外的另一类隐性冲突。

4) 提示词层面的所有权规则。ownershipRule 为每个队友生成专属人设文本:有owns时,"Do not create, edit, move or delete anything outside them —— a teammate is working there right now and your write would be silently lost";没有owns时,要求队友把对共享代码的改动report上来而非擅自修改。团队约定提示词 还给出了两条决定团队成败的规则:ONE WRITER PER FILE(协调者自身也受约束——队友持有期间,发现其文件有错应send_message派回给持有者,而不是自己动手修)和SETTLE THE CONTRACTS FIRST(两个队友接触到的接口/签名/schema/事件名必须在开工前写入双方任务书,否则"they will each invent a reasonable version and neither will fit")。后者是对文档"写入内容矛盾 → 主修裁决"的预防式补充:矛盾最好的解决方式是从源头消灭。

六、通信协议:SendMessage 规范与通信时机

消息类型

通信时机

蚁群仿生版 在此基础上新增了"侦察完成"与"审查完成"两个事件,并引入信息素(Stigmergy)间接通信:用 Task 的 metadata 承载discovery(斥候发现)、progress(工蚁进度)、warning(护法告警)、completion(完成标记)、repellent(负信息素,标记失败路径)五类信息素,决策规则为:discovery/completion 优先分配、warning 降权、repellent 需主修评估,并用 ε-greedy(90% 按信息素强度、10% 随机)避免所有 Agent 挤同一条路。

dsh-ccg 用另一套更工程化的"通信纪律"实现了同等目标:TEAM_FRAMING 规定了队友的回报义务——完成时报告一次自包含的"改了什么+如何验证";更早、不等询问地报告任何改变他人工作前提的发现(改动了共享契约、遇到阻塞、发现自己假设错误);"迟到的完整报告不如及时的半成品报告"。团队约定 则要求协调者把收到的每份报告当作路由信号:队友报告契约变更时,立即send_message通知依赖它的人;对意外结果先自行验证再采信;"integration and the final verdict stay yours; never let a teammate ratify its own work"。

七、状态共享与错误处理

状态共享

TaskCreate: 主修创建总任务+子任务 TaskUpdate: 道侣更新子任务状态 TaskList: 主修查看全局进度

状态流转:

pending → in_progress → completed → blocked (需等待依赖)

蚁群仿生版 在 TaskUpdate 的 metadata 中附带信息素,并补充TaskGet查看详情。

错误处理与容错

单 Agent 失败:

道侣失败 → 报告主修 → 主修评估影响 ├─ 可重试 → 同一道侣重试（≤2次） ├─ 需换策略 → 主修调整方案后重新分配 └─ 不可恢复 → 主修接管该子任务

通信超时:

道侣无响应 → 主修等待30s → 再次发送 → 仍无响应 → 标记异常，重新分配

降级策略:

多Agent协同失败 → 降级为单Agent串行执行 宁可慢，不可错。

仿生版为"可重试"分支追加了一步:失败先释放 repellent 信息素,主修换策略时参考它避开死路。过载保护(来自 自适应并发一节)同样可视为容错的主动形态:Agent 连续失败 ≥2 次 → 减少并发;429 限流 → 暂停派发;子任务膨胀 >30 → 停止产生新子任务,先完成现有的。

dsh-ccg 中与之对应的是"快速失败+显式拒绝"风格:hireApprovalQuestion 在招聘前向用户确认角色/模型/独占文件;readApproval 采用 fail-closed——任何非明确批准的回答都视为拒绝;用户拒绝时返回hired: false的正常结果而非异常,并附 处置指引:自己接手这部分,或提出更小的拆分,"never route around it by starting the same agent another way"。这对应文档容错思想里的"降级":多 Agent 协同受阻时,回退到单 Agent 串行是合法路径而非失败。

八、结果汇总:流程、统一 Commit 与报告模板

汇总流程

1. 收集所有道侣完成报告
2. 验证文件完整性(所有预期文件存在)
3. 验证内容一致性(交叉引用正确)
4. 统一 git add + commit
5. 输出汇总报告

蚁群仿生版 将流程扩展为七步,在第 2 步插入"变更 >3 个文件时建议派护法审查",第 3 步为审查产生的修复任务留了回环。

统一 Commit 规范

# 主修负责最终commit，道侣不单独commit git add -A git commit -m "feat: {任务描述} Co-authored-by: Agent-A Co-authored-by: Agent-B"

汇总报告模板

🕸 天罗收阵！ 【阵法】{团队名称} 【阵员】{Agent数量} 道侣 【战果】 - Agent-A: {文件数} 文件，{行数} 行 - Agent-B: {文件数} 文件，{行数} 行 【验证】全部文件存在 ✓ | 交叉引用正确 ✓ 【耗时】{总时间}

仿生版报告模板在此之上增加了【生命周期】(侦察→工作→审查→完成)与【信息素】计数(discovery/completion/warning/repellent 各若干条),让"隐性协调成果"也可被度量。

九、最佳实践:命名规范、启动模板与强约束提示词

命名规范

team_name: "{项目}-{任务类型}" # 如 "abyss-skill-expansion" agent_type: "{角色}" # 如 "lead", "developer", "reviewer" description: "一句话说明团队目标"

dsh-ccg 中 hire 工具的description参数被定义为 "A short label for this teammate (3-5 words), shown while they work",与"3-5 词短标签"的落地形态一致;describeTeam 生成的工具描述也复述了启用标准:"give each teammate the files it alone may write"。

主修启动模板

你是天罗主修，负责协调多Agent协同任务。 职责： 1. 将大任务分解为独立子任务 2. 为每个道侣分配文件集合（不可重叠） 3. 追踪进度，处理阻塞 4. 汇总结果，统一验证 铁律： - 每个文件只能分配给一个Agent - 独立任务必须并行启动 - 收到所有道侣完成消息后才能进入汇总

仿生版把"主修职责"改写为五阶段生命周期(侦察→分配→审查→修复→汇总),并在铁律中追加"关注信息素:discovery 优先分配,repellent 避免分配""所有子 Agent 完成后必须 close_agent 回收"。

道侣启动模板

你是天罗道侣，负责执行分配的子任务。 职责： 1. 严格按照分配的文件列表操作 2. 不触碰未分配的文件 3. 完成后通过SendMessage报告主修 4. 遇阻时立即报告，不自行扩大范围 报告格式： - 完成：列出创建/修改的文件+行数 - 阻塞：说明原因+建议方案

强约束模板(Codex)

你仅可修改：{owned_files} 不得触碰未分配文件；若需要跨文件修改，先报告阻塞。 输出必须包含：变更文件、验证命令、剩余风险。

蚁群仿生版 提供了三个可直接复用的强约束模板,Worker 指令模板与上面基本一致并增加了"若失败,返回最小复现与替代方案";Reviewer 模板要求按"正确性 > 安全性 > 回归风险 > 风格"输出问题清单、无问题时明确写 "no findings";Lead 汇总模板要求输出已完成项/阻塞项/剩余风险/下一步命令。这套"输出必须含变更文件+验证命令+剩余风险"的格式,与 roles.js 中 builder persona 的 "Finish with the exact command that verifies your work" 是同一种工程取向:每个子任务的交付物必须自带可执行验证,主修才能机械地做完整性检查。

团队入口:/ccg:team 八阶段流水线

在 ccg-workflow 的命令侧,团队能力通过/ccg:team <需求描述>一键执行完整 8 阶段流水线(见 SKILL.md 企业级角色扩展):

Phase 0: PRE-FLIGHT → 环境检测 + 参数解析 Phase 1: REQUIREMENT → Lead 需求增强 → mini-PRD Phase 2: ARCHITECTURE → Codex∥Gemini 外援 + Architect teammate 出蓝图 Phase 3: PLANNING → Lead 拆任务 → 零决策并行计划 Phase 4: DEVELOPMENT → Dev×N teammates 并行编码（文件隔离） Phase 5: TESTING → QA teammate 写测试 + 跑全量验证 Phase 6: REVIEW → Codex∥Gemini 外援 + Reviewer teammate 综合审查 Phase 7: FIX → Dev teammate(s) 修复 Critical（最多 2 轮） Phase 8: INTEGRATION → Lead 全量验证 + 报告 + 清理

其中 Phase 4 的"文件隔离"正是本文第五节黄金规则的流水线级应用;角色按阶段 spawn、用完 shutdown,Phase 8 统一 TeamDelete,与 Codex 映射表中"收尾回收close_agent"的纪律对应。

十、审查清单(可直接用作收工门禁)

• 任务分解无文件冲突
• 依赖关系明确
• 通信协议遵守
• 状态同步及时
• 错误处理完备
• 结果汇总完整

结合 dsh-ccg 的机制,前两项可以做成自动化检查:文件冲突由owns预检机械拦截(team.js 冲突检查),依赖关系由斥候的 discovery 信息素显式登记,避免主修凭印象判断。相关行为由 dsh-ccg/test/team.test.mjs 等测试覆盖,可作为机制正确性的佐证入口。

小结

multi-agent.md 的价值在于把"多 Agent 并行"从口号拆成了可执行的检查序列:决策树定"要不要并行",动作映射表定"用什么工具并行",文件锁定定"并行不出乱子",通信协议与状态共享定"主修看得见全局",容错与降级定"失败有退路",统一 commit 与汇总报告定"收口可审计"。dsh-ccg 的实现 则展示了同一套原则在工具层如何落地——招聘前预检文件所有权、持久化 roster、fail-closed 的批准门禁、以及把"ONE WRITER PER FILE / SETTLE THE CONTRACTS FIRST"写进协调者系统提示词。阅读时建议以秘典为方法论主干、以源码为机制注脚对照阅读,并可直接从 templates/skills/domains/orchestration/SKILL.md 进入整个协同编排知识域继续深入。

• 人工智能
• AI 应用
• 开发工具
• CLI
• AI Agent
• dsh-plugin
• DeepSeek