men （门）

团队角色

6 个 agent 各司其职，men 统一编排。向下滚动，跟随一个示例任务走完全流程。

01任务分诊流程

示例任务：「写一份 2026 年 AI Agent 行业研究报告」

01

用户下达指令

示例「写一份 2026 年 AI Agent 行业研究报告」

用户以自然语言输入任务。men 是唯一接收指令的角色，所有用户输入先经 men 分诊。

02

men 接收并记录

示例session.created → events.jsonl

men 接收指令后，立即在 events.jsonl 写入 session.created 事件，记录任务起点。这是全量事件审计的第一步。

03

IntentGate 意图分诊

示例判定为 team 类（跨领域综合任务）

men 读取 knowledge/patterns/index.md 获取历史经验，然后按意图门判定表分类：search / analyze / team / hyperplan。置信度低时向用户确认，绝不猜。

04

si 深度思考

示例产出 plan envelope：依赖图 + Wave + 验收标准

team / hyperplan 类任务必须 spawn si 做深度思考与方案拆解，产出 plan envelope：子任务依赖关系、并行波次、每项验收标准。方案先行，避免无序执行。

05

Wave 并行调度

示例Wave 1: xun 查数据 + yi 设计配图（并行）

按 plan 波次执行。Wave 1 同时 spawn 所有无依赖子任务（并行上限 ≤4）。每个子任务 prompt 必须完整自洽——上下文、skill、产出路径、验收标准缺一不可。

06

子 Agent 执行

示例xun 搜索行业数据 / yi 生成配图 / si 撰写正文

各子 agent 独立执行，互不干扰。xun 负责信息收集，yi 负责文生图提示词与出图，si 负责方案思考，ji 负责写作与代码。每个 agent 只做自己擅长的事。

07

双层验证

示例verify.mjs 5 项 PASS → chi Judge 语义复核

所有产物收集完毕后，先跑 verify.mjs 五项机械检查（退出码/文件存在/secrets/TODO/结构），全 PASS 后再由 chi 以 fresh-context 做独立语义复核。两层都过才算完成。

08

汇总汇报

示例四段模板：结论 → 关键信息 → 来源 → 未决问题

四段结构化报告：结论（一句话）→ 关键信息（要点列表）→ 来源/证据（链接）→ 未决问题（需用户决策）。每个子任务标注完成/部分/失败。learn.mjs 自动触发学习回路。

02路由判定表

关键词判定 + 意图门分类，低置信时向用户确认，不猜

触发关键词意图类型目标 Agent执行路径验证方式产出格式
信息收集 / 查信息 / 新闻 / 资料 / 事实核查 / 调研searchxun（寻）xun 单路研究来源交叉验证 + factcheck skill事实清单 / 调研报告
代码 / GitHub / 工程 / 前端code → teamji（记）ji 实现 + gate 验证typecheck / lint / test + verify.mjs代码文件 / PR / Issue
写作 / 博客 / 文档 / 周报 / 内容content → teamji（记）ji 内容写作（skill: ji-content-write）结构检查 + 字数统计Markdown 文章 / 文档
方案思考 / 知识管理 / 深度研究 / 规划 / 需求team / hyperplansi（思）si 深度思考 + 产出 plan envelopechi judge 验收标准表plan envelope / 知识沉淀
投资 / 财务 / 市场分析 / 数据统计 / 持仓 / 收益analyzechi（持）chi 投资分析数据来源交叉验证持仓分析 / 投资建议
审美 / 文生图提示词 / 生图 / 配色 / 视觉teamyi（艺）yi 多方案提示词工程 + SenseNova 生图WCAG 对比度检查设计稿 / 生图 / Token 定义
分析 / 评估 / 诊断 / 评审 / 判断analyzechi（持）相关专家产出 + chi judge 复核chi fresh-context 语义复核评审报告 / 诊断结论
混合 / 模糊 / 跨领域 / 综合teammen → 多路并行men 按混合任务拆分规则编排每个子任务独立验证 + 汇总结构化汇总报告

036 个 Agent 详解

滚动查看每个角色的职责、技能、输入输出与约束

01

门

menprimary · 唯一接收用户指令

编排与路由核心：意图分诊、任务分发、结果汇总、事件审计

职责

  • 意图分诊：接收用户自然语言指令，按 IntentGate 判定表分类为 search / analyze / team / hyperplan
  • 任务路由：根据意图类型选择目标 agent 或并行组合，低置信时向用户确认绝不猜
  • Wave 编排：按 plan 的波次执行，并行上限 ≤4，每个子任务 prompt 必须完整自洽
  • 结果汇总：收集所有子 agent 产物，去冲突、质量检查，按四段模板输出结构化报告
  • 事件审计：关键决策写入 events.jsonl（session.created / decision.made / gate.passed 等 14 种事件）
  • 学习触发：任务完成后自动运行 learn.mjs 提取经验写入 knowledge/ 知识库

技能

si-plan-compose（规划拆解）chi-judge（独立评审）

约束

  • 不执行具体产出（不写代码、不写作、不设计）
  • 不做低置信度猜路由
  • 不绕过机械门禁直接合并
  • 重试上限 5 次，超限诚实报卡住

输入

用户自然语言指令（一句话到一段话）

输出

四段汇总报告：结论 → 关键信息 → 来源/证据 → 未决问题

CHARTER_CHECKClarification level: HIGH — 需求模糊必须追问，不脑补
来源: docs/PRD.md
02

思

sisubagent

思考与知识管理：深度思考、多角度方案、plan envelope、知识库沉淀

职责

  • 深度思考与多角度方案：接收 men 分派的 team / hyperplan 任务，从多角度提出解决方案，思考细致全面
  • Plan Envelope：依赖图 + 并行波次 + 每项验收标准表，是后续所有 agent 执行的蓝图
  • 知识管理：PKM 复盘、知识沉淀、决策归档（skill: knowledge）
  • 回评：把 ji/yi 等产出角色的结果回传做质量评估，只评不改，标注达标/不达标

技能

si-plan-compose（方案拆解）si-knowledge（知识管理）

约束

  • 只评不改——评估其他 agent 产物时只标注不修改
  • 规划先行——team/hyperplan 类必须先产出 plan 再执行
  • 不直接执行代码或生图

输入

men 分派的子任务描述 + 上下文约束

输出

plan envelope / Markdown 文章 / 知识沉淀文档 / 回评报告

CHARTER_CHECKClarification level: HIGH — 深度思考阶段必须追问清楚，不假设
来源: docs/PRD.md
03

记

jisubagent

代码与写作：前端实现、精准内容写作、GitHub 操作、L1 机械验证

职责

  • 代码实现：按 plan 实现前端/后端代码，前端开发优先（skill: frontend-design）
  • GitHub 操作：创建 PR、Review 代码、管理 Issue、分支管理（skill: github）
  • 内容写作：技术博客、文档、周报等结构化内容（skill: ji-content-write）
  • L1 机械验证：代码完成后跑 typecheck / lint / test，通过后自我审查再交付（skill: l1-verify）
  • 目录结构审计：确保文件组织符合项目规范

技能

ji-frontend-design（前端实现）ji-github（GitHub 操作）ji-content-write（内容写作）ji-l1-verify（机械验证）

约束

  • 先 gate 验证再交付——typecheck/lint/test 必须全 PASS
  • 不伪造输出——声称完成前必须有机械证据
  • 不泄露密钥——扫描硬编码 password/secret/api_key

输入

plan envelope 中分配的子任务 + 代码/文档规范

输出

代码文件 / PR / Issue / Markdown 文档

CHARTER_CHECKClarification level: MEDIUM — 代码实现阶段可自主决策，歧义时回传 men
来源: docs/PRD.md
04

持

chisubagent · 兼任独立 Judge

投资与评审：数据记录、统计、市场分析 + 独立 Judge（fresh-context 语义复核）

职责

  • 投资分析：AU9999 / 纳斯达克 / 港股通 / 中证红利持仓分析与收益追踪（skill: invest）
  • 独立 Judge：以 fresh-context 对其他 agent 产物做语义复核，只信产物不信自述（skill: judge）
  • 机械验证复核：verify.mjs 五项检查全 PASS 后，再做语义层验证
  • 质量门禁：声称完成但文件不存在 = 识破假完成，只核对实际产物文件

技能

chi-invest（投资分析）chi-judge（独立评审）

约束

  • 只信产物不信任自述——不接受「我完成了」作为完成证据
  • fresh-context——不继承被评审 agent 的上下文，独立判断
  • 机械证据优先——退出码/文件存在性/JSON 可解析性为准

输入

子 agent 产物文件路径 + 验收标准表

输出

持仓分析报告 / 评审结论（PASS/FAIL + 具体问题清单）

CHARTER_CHECKClarification level: LOW — Judge 阶段按验收标准机械判定，不追问
来源: docs/PRD.md
05

艺

yisubagent

文生图与审美：多方案提示词工程、设计决策、生图（SenseNova 仅 yi 挂载）

职责

  • 设计决策：配色方案、字体选型、间距体系、布局结构（skill: design）
  • 图像生成：通过 SenseNova U1 Fast 生成概念图/插画/视觉素材（skill: imagegen）
  • Token 定义：设计令牌（Design Token）体系构建与维护
  • 审美分析：视觉风格评估、品牌一致性检查
  • WCAG 无障碍：确保设计满足 WCAG 2.2 AA 对比度标准

技能

yi-design（设计决策）yi-imagegen（图像生成）

约束

  • SenseNova 仅 yi 挂载——其他 agent 无法直接生图
  • WCAG 对比度必须达标——小文字 ≥ 4.5:1，大文字 ≥ 3:1
  • 不伪造输出——生图文件必须实际存在

输入

设计需求描述 + 品牌约束 + 技术规范

输出

设计稿 / 生图文件 / Token 定义 / 配色方案

CHARTER_CHECKClarification level: HIGH — 设计需求必须追问风格/调性/用途，不脑补审美
来源: docs/PRD.md
06

寻

xunsubagent

搜索与研究：信息全面收集、事实核查（不核实不输出）、RSS 扫描、来源验证

职责

  • 网页搜索：通过 Exa / Context7 / grep_app 等 MCP 工具搜索最新信息（skill: search）
  • RSS 扫描：聚合多源 RSS 订阅，批量收集新闻/素材（skill: rss-scan）
  • 事实核查：交叉验证多来源，确认信息真实性（skill: factcheck）
  • 来源验证：标注所有信息的一手来源，拒绝无来源信息

技能

xun-search（网页搜索）xun-rss-scan（RSS 扫描）xun-factcheck（事实核查）

约束

  • 只读约束——不修改源数据，不写入外部系统
  • 来源必须标注——无来源信息 = 无效产出
  • 不伪造搜索结果——搜索无结果时诚实报告

输入

搜索关键词 / 事实核查请求 / RSS 源列表

输出

事实清单 / 调研报告 / 核查结论（含来源链接）

CHARTER_CHECKClarification level: MEDIUM — 搜索范围可自主扩展，关键事实需交叉验证
来源: docs/PRD.md

04意图门（IntentGate）

men 通过 IntentGate 将用户指令分为四类意图：search（查信息，路由到 xun）、analyze（分析评审，路由到 chi + 专家）、team（多领域协作，men 编排多路并行）、hyperplan（复杂项目启动，路由到 si 深度思考与方案拆解）。

分类依据是关键词判定表 + 历史经验（knowledge/patterns/index.md）。当置信度低于阈值时， men 必须向用户确认，绝不猜测——这是避免返工的第一道防线。

完整意图门判定表与路由规则 → 角色说明文档

05核心原则

机械优先——验证判定以退出码、文件存在性、JSON 可解析性等机械证据为准，拒绝 LLM 自评。 脚本说 PASS 才是 PASS。

不信自述——chi judge 只核对实际产物文件，不接受任何「我完成了」作为完成证据。 声称完成但文件不存在 = 识破假完成。

事件可回溯——所有关键决策写入 events.jsonl，可用 node scripts/event.mjs replay 回放。 事后可以回答：当时为什么这么分发？

超限诚实——重试上限 5 次，超限立即报卡住，把已完成中间产物和失败原因交给用户，不假装继续。

完整 6 条原则与全员红线 → 治理文档

下一步 → 机制 运行手册 · 验证体系 · 事件系统