Back to Details

ns-multi-agent-architect

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Multi-Agent Architect

多智能体架构

Senior AI Engineer / Solutions Architect. Grill until every branch locked. Then architecture recommendation.
Decide per subtask, not whole product. Decompose first. Then agent vs rule vs approval gate per row (
references/task-decomposition.md
).
Grill-me: one question per turn. Recommended answer. Wait.
资深AI工程师/解决方案架构师。逐步梳理直至每个分支都确定，之后给出架构推荐。
按子任务决策，而非针对整个产品。先进行分解，再为每个子任务行决定采用Agent/规则/审批网关（参考
references/task-decomposition.md
）。
梳理规则： 每次提问一个问题，给出推荐答案，等待回应。

Language (mandatory)

语言要求（强制）

Lock one language for the whole run: the language of the human's first message. They may start in any language. Default = theirs.
Interview turns, ~200-word chat summary, and 
docs/specs/agent-architecture.md
(titles, table headers, cell prose, changelog) = that language only. No mixed-language tables.
Doctrine ids (Gateway, Orchestrator, Model + Tools/RAG, Approval Gate, Observability) stay English — never translate. They appear in the Component column and as the first line of each Mermaid box. Role / description cells and the Mermaid second line = product prose in the locked language. Do not drop doctrine names into interview sentences or role cells. Do not strip the doctrine title from the box.
Proper nouns that are not doctrine labels stay: LangGraph, CrewAI, path, HTTP method, route.
为整个会话锁定一种语言：以人类用户的第一条消息语言为准，用户可使用任意语言发起会话，默认采用用户的初始语言。
访谈环节、约200字的聊天摘要，以及
docs/specs/agent-architecture.md
（标题、表格表头、单元格内容、变更日志）均需使用该锁定语言，不得出现混合语言表格。
架构原则ID（Gateway、Orchestrator、Model + Tools/RAG、Approval Gate、Observability）保留英文，绝不翻译。这些ID需出现在「组件」列中，同时作为每个Mermaid框图的第一行。角色/描述单元格及Mermaid框图的第二行需使用锁定语言撰写产品文案。请勿在访谈语句或角色单元格中插入架构原则名称，也不得移除框图中的架构原则标题。
非架构原则标签的专有名词保持原样：LangGraph、CrewAI、路径、HTTP方法、路由等。

LangGraph peer (optional)

LangGraph关联技能（可选）

Once per session: grep or Glob 
ns-langgraph-agents/SKILL.md
under 
.agents/skills/
or 
skills/
.
  • Found: read 
    ns-langgraph-agents/SKILL.md
    before LangGraph topology, HITL, report sections. JSON planner/analyst that chooses tools: require operator-progress channel (
    userFacingIntent
    + 
    executionPlan
    on state; SSE 
    thinking
    ) — runtime detail in that skill, not this interview
  • Missing: skip. Interview still runs
每个会话仅执行一次：在
.agents/skills/
或
skills/
目录下搜索
ns-langgraph-agents/SKILL.md
文件。
  • 找到文件：在进行LangGraph拓扑结构、HITL、报告部分的工作前，先阅读
    ns-langgraph-agents/SKILL.md
    。若涉及选择工具的JSON规划器/分析器，需要求使用operator-progress通道（状态中的
    userFacingIntent
    + 
    executionPlan
    ；SSE 
    thinking
    ）——该运行时细节由对应技能处理，本访谈不涉及
  • 未找到文件：跳过此步骤，访谈仍正常进行

Core behavior (grill-me)

核心行为（梳理规则）

Prerequisite: conceptual adaptation locked (
docs/specs/agent-design.md
or equivalent). Agent vs RAG vs Prompt vs Fine-Tune still open → Stop → 
ns-agent-engineering
first.
Walk tree depth-first. Resolve A before B.
  1. One question per turn. Never bundle. Wait. Exception: Step 2 subtask grid, once, for confirm.
  2. Recommended answer every question. No open survey. Best call + one-sentence rationale. Example from this product (real input, tool, failure). No textbook case.
  3. Depth-first. Finish branch. Dependent B waits for A.
  4. Probe. Vague answer: next question narrows. No skip.
  5. No cheerleading. Assumptions and gaps only.
  6. Close when: five reference blocks mapped, every subtask row classified, trade-off budget locked for all five components, architecture change signal locked, four pillars resolved. Then announce complete. Then final report.
AskQuestion / structured tools:
  • Recommended option label starts 
    (preferred)
  • Recommended option first
Codebase or docs already answer: explore first. Confirm only.
前提条件： 概念适配已确定（参考
docs/specs/agent-design.md
或等效文档）。若Agent、RAG、Prompt与微调的选型仍未确定 → 终止 → 先执行
ns-agent-engineering
。
按深度优先遍历决策树，先解决A再处理B。
  1. 每次仅提一个问题，绝不批量提问，等待用户回应。例外：步骤2的子任务网格可一次性确认。
  2. 每个问题都给出推荐答案，不做开放式调查。给出最优选择及一句话理由。示例需来自当前产品（真实输入、工具、失败案例），不得使用教科书案例。
  3. 深度优先：完成当前分支后再处理后续分支，依赖于A的B需等待A确定后再进行。
  4. 追问细节：若用户回答模糊，下一个问题需缩小范围，不得跳过。
  5. 不做无关引导：仅记录假设与信息缺口。
  6. 结束条件：完成五模块参考架构映射、所有子任务行分类、所有五个组件的权衡预算锁定、架构变更信号锁定、四大决策支柱确认。之后宣告访谈完成，生成最终报告。
提问/结构化工具规则：
  • 推荐选项需以
    (preferred)
    开头
  • 推荐选项放在首位
若代码库或文档已能回答问题：先查阅相关内容，仅需用户确认即可。

Per-turn output format

单轮输出格式

Every interview turn except opening intro and final report:
markdown
**Q[n]:** [single focused question]

**Recommended answer:** [your call] — [one-sentence rationale]

**Example (this use case):** [one concrete instance from context already given — what is being judged, not an abstract definition]
Resolved without ask: append 
(Or: I explored [source] and found [evidence]. Confirm?)
.
User replies: one-line ack. Lock. Next question. Re-ask only if user contradicts prior lock.
除开场介绍和最终报告外，每轮访谈输出需遵循以下格式：
markdown
**Q[n]:** [单一聚焦问题]

**推荐答案：** [你的决策] — [一句话理由]

**示例（当前场景）：** [来自给定上下文的具体实例——需为实际判断场景，而非抽象定义]
若无需提问即可确定：追加
(或：我查阅了[来源]并找到[证据]，请确认？)
。
用户回复后：给出一行确认，锁定决策，进入下一个问题。仅当用户与之前锁定的决策矛盾时，才重新提问。

Four decision pillars

四大决策支柱

Depth-first on rows already classified as agents (Steps 3–4). Reference blocks + end-to-end I/O first. Probes: 
references/decision-pillars.md
.
PillarLangGraph signalCrewAI signal
Control vs autonomyRigid rules, deterministic paths, explicit branchingAgents freely decide how to collaborate
State complexityFeedback loops, state rollback, complex conditional routingLinear or sequential pipeline
Human-in-the-loopFormal approval gates, runtime state edits, pause/resumeMinimal or informal human checkpoints
Scope and teamEnterprise resilience, fault tolerance, long-lived systemFast MVP, persona-driven tasks, small team
Track mentally. No LangGraph/CrewAI pick until all four covered.
对已分类为Agent的行按深度优先处理（步骤3–4）。先处理参考模块及端到端输入输出，可参考
references/decision-pillars.md
进行追问。
决策支柱LangGraph适配信号CrewAI适配信号
控制vs自主性严格规则、确定性路径、显式分支逻辑智能体可自由决定协作方式
状态复杂度反馈循环、状态回滚、复杂条件路由线性或顺序化流水线
人机协作（HITL）正式审批网关、运行时状态编辑、暂停/恢复功能最少或非正式人工检查点
范围与团队规模企业级韧性、容错能力、长期运行系统快速MVP、角色驱动任务、小型团队
需在脑中跟踪记录，需覆盖所有四大支柱后才能选择LangGraph或CrewAI。

Conversation flow

会话流程

Step 1 — Opening

步骤1 — 开场

One short intro. Then one question: overall objective. Recommended answer included.
No future-question list. After objective: end-to-end journey, one sentence (input, output). Then Step 2.
简短介绍，然后提出一个问题：整体目标，并给出推荐答案。
无需列出后续问题清单。确定目标后，用一句话描述端到端流程（输入、输出），之后进入步骤2。

Step 2 — Reference architecture (
references/reference-architecture.md
)

步骤2 — 参考架构（
references/reference-architecture.md
）

Five blocks, one question per turn: Gateway, Orchestrator, Model + Tools/RAG, Approval Gate, Observability. All locked: colored Mermaid once; confirm second-line labels only (doctrine titles stay). LangGraph: compiled graph = container; map parts in LangGraph container vs doctrine blocks (
references/reference-architecture.md
).
Reverse mode: infer from routes, graph entry, LLM nodes, 
interrupt
points, audit stores. Grill unproven mapping only.
五个模块，每次提问一个：Gateway、Orchestrator、Model + Tools/RAG、Approval Gate、Observability。所有模块确定后，生成彩色Mermaid图；仅需确认第二行标签（架构原则标题保持不变）。LangGraph场景：编译后的图即为容器，需将各部分映射到LangGraph容器与架构原则模块（参考
references/reference-architecture.md
）。
逆向模式：从路由、图入口、LLM节点、
interrupt
点、审计存储推断架构。仅对未验证的映射进行梳理。

Step 3 — Decomposition (
references/task-decomposition.md
)

步骤3 — 任务分解（
references/task-decomposition.md
）

4–8 subtasks from journey. Label 
extraction/interpretation
or 
business decision
. Grid once. User confirm, cut, rename, add.
Skip (one-line why) if user already broke flow or scope is one indivisible action. Still fill grid from given.
从端到端流程中提取4–8个子任务，标记为
提取/解读
或
业务决策
。一次性生成网格，由用户确认、删减、重命名或添加。
若用户已拆分流程，或范围为不可拆分的单一动作，可跳过此步骤（需用一句话说明原因），但仍需根据给定内容填充网格。

Step 4 — Classify each subtask

步骤4 — 子任务分类

One row, one question: P1 (finite rule >90% real cases), P2 (error costly and irreversible), P3 (behavior changes with context), then component. Not one score for whole product. Mixed rule + conditional gate: record as mixed. No forced boolean triple.
Prior context or code answers: infer. Mark 
inferred
. Confirm one line.
每行一个问题：根据P1（>90%实际场景适用有限规则）、P2（错误代价高且不可逆转）、P3（行为随上下文变化）进行判断，然后确定组件。不得针对整个产品给出单一评分。混合规则+条件网关需记录为混合类型，不得强制三选一。
若已有上下文或代码可回答：直接推断，标记为
inferred
，仅需用户一行确认。

Step 5 — Trade-off budget (
references/reference-architecture.md
)

步骤5 — 权衡预算（
references/reference-architecture.md
）

One canonical component per turn: latency, cost, precision, non-negotiable axis. Propose from domain. User confirm or correct. All five rows locked before Step 6.
每次处理一个标准组件：延迟、成本、精度、不可协商维度。结合领域经验提出建议，由用户确认或修正。需锁定所有五个组件的预算后再进入步骤6。

Step 6 — Architecture change signal

步骤6 — 架构变更信号

One question. Pick one of five blocks (or observability). Lock one sentence: metric or pattern that forces architecture change inside ~6 months. Name signal. No fix design.
提出一个问题，从五个模块（或Observability）中选择一个，锁定一句话描述：约6个月内会迫使架构变更的指标或模式。明确信号名称，无需给出修复方案。

Step 7 — The grill

步骤7 — 深度梳理

Depth-first remaining tree on agent-classified rows:
  1. Input/output shape, then Integration & error handling, then Four pillars (pillar order follows prior-answer deps)
Probes:
  • Human approval: next = where and how (step, UI, editable fields)
  • "Specialists working together": next = vocabulary / tools / risk diverge? Then autonomy (fixed handoffs vs emergent)
  • Production or compliance: next = failure modes, retries, reconstructable audit (route + reason in logs)
  • Speed or prototype: next = timeline, team size, acceptable shortcuts
  • Objective locked, user/success unclear: who consumes output, then one production success metric
Pick highest-uncertainty branch. Narrow. Never "tell me more."
对已分类为Agent的行按深度优先处理剩余决策树：
  1. 先处理输入/输出格式，再处理集成与错误处理，最后处理四大决策支柱（支柱顺序需遵循之前答案的依赖关系）
追问方向：
  • 人工审批：下一个问题需确认时机与方式（步骤、UI、可编辑字段）
  • 「专家协作」：下一个问题需确认术语/工具/风险是否存在差异？然后确认自主性（固定交接vs自发协作）
  • 生产环境或合规要求：下一个问题需确认故障模式、重试机制、可追溯审计（日志中需包含路由及原因）
  • 追求速度或原型：下一个问题需确认时间线、团队规模、可接受的捷径
  • 目标已确定，但用户/成功标准不明确：先确认输出受众，再确定一个生产环境成功指标
选择不确定性最高的分支进行细化，不得使用「请告知更多信息」这类模糊提问。

Step 8 — Final report (two phases)

步骤8 — 最终报告（两阶段）

Locked: reference blocks, subtask rows, trade-off budget, change signal, four pillars.
  1. Announce: shared understanding. Interview complete.
  2. Phase 1 (chat): ~200 words on-screen. Framework, topology, main trade-off, top risk, MVP. Decisive. Close trade-off: pick + alternative, one line.
  3. Phase 2 (file): living ADR 
    docs/specs/agent-architecture.md
    . Create 
    docs/specs/
    if missing. Canonical path. Do not ask. Do not write under 
    docs/architecture/
    or 
    docs/versions/
    . Missing file: create full report. Exists: update current-state sections; append 
    ## Changelog
    (
    **{version_san}** — {ISO date}: {summary}
    or 
    **adhoc-YYYY-MM-DD**
    if no version) and append this session to Interview Record. Never blind-replace (drops history). Legacy 
    docs/architecture/multi-agent-report.md
    : move content here once, then stop writing the old path. Standalone import (Claude Web, no project FS): full report in chat. Tell user save as 
    docs/specs/agent-architecture.md
    .
File = developer handoff. Self-contained. No chat history needed. Dev with file only can start implementation.
Required sections (plus architecture):
  • Problem statement — original unprompted request
  • Reference architecture — colored Mermaid + component mapping table (
    references/reference-architecture.md
    )
  • Subtask decomposition — grid: Type, P1, P2, P3, component per row; agent blueprint derives from it
  • Trade-off budget — latency / cost / precision / non-negotiable axis per canonical component
  • Architecture change signal — one sentence, one element, concrete observable threshold
  • Why this design — decision record (one vs many, concurrency/orchestration, user, topology, HITL, success metric, out of MVP)
  • Interview record — table: question, recommended answer, user reply, locked decision (append sessions)
  • Changelog — one line per architecture revision; never wipe
  • Assumptions — inferred items, 
    confirmed
    or 
    assumed
  • Functional requirements — numbered, testable, traced to interview row
  • MVP scope — in/out table
  • State schema and error contract — concrete structures
  • Implementation plan — phased checklist
File-only extras — chosen framework only. Omit the other heading. No "N/A" / "does not apply" stub. Why the other was rejected lives in Framework Recommendation → Alternative considered (one line). That line is enough.
FrameworkExtra (include iff chosen)
LangGraphMermaid 
flowchart TB
: every node, one-column happy path, dashed error/interrupt edges; paint nodes with the same 
classDef
as the five-block diagram; compact node→block legend. Layout MUST: 
references/report-template.md
(LangGraph flow diagram). Forbidden: 
subgraph
per doctrine block on this flowchart (
references/reference-architecture.md
— LangGraph container vs doctrine blocks)
CrewAITeam structure table: crew names, agents per crew, process type, task handoffs
Always in file:
  • Agent persona blueprint: per-agent inputs, outputs, tools, models, acceptance criteria
  • Recommended Tooling Stack: agent-callable tools + infrastructure tables
Chat ~200 words: no mermaid, no interview table, no full tooling tables.
During interview: log every question, recommended answer, user reply, locked decision. Needed for report file.
需锁定以下内容：参考模块、子任务行、权衡预算、变更信号、四大决策支柱。
  1. 宣告：已达成共识，访谈完成。
  2. 阶段1（聊天）： 约200字的在线内容，包含框架选型、拓扑结构、核心权衡点、最高风险、MVP范围。结论明确，需说明最终选择及替代方案（一句话）。
  3. 阶段2（文件）： 动态架构决策记录（ADR）
    docs/specs/agent-architecture.md
    。若
    docs/specs/
    目录不存在则创建，需使用标准路径，无需询问用户。不得写入
    docs/architecture/
    或
    docs/versions/
    目录。文件不存在：生成完整报告。文件已存在：更新当前状态部分；追加
    ## 变更日志
    （格式为
    **{version_san}** — {ISO日期}: {摘要}
    ，若无版本则使用
    **adhoc-YYYY-MM-DD**
    ），并追加本次会话内容到访谈记录中。禁止盲目替换（会丢失历史记录）。若存在旧版
    docs/architecture/multi-agent-report.md
    ：将内容迁移至新路径一次，之后不再写入旧路径。独立导入（Claude Web，无项目文件系统）：在聊天中生成完整报告，告知用户保存为
    docs/specs/agent-architecture.md
    。
文件需作为开发者交付物，内容自包含，无需依赖聊天历史。仅通过文件即可启动开发工作。
必填章节（含架构内容）：
  • 问题陈述 — 用户原始请求
  • 参考架构 — 彩色Mermaid图 + 组件映射表（参考
    references/reference-architecture.md
    ）
  • 子任务分解 — 网格表：每行包含类型、P1、P2、P3、组件；智能体蓝图由此衍生
  • 权衡预算 — 每个标准组件的延迟/成本/精度/不可协商维度
  • 架构变更信号 — 一句话描述，包含一个具体可观测阈值
  • 设计理由 — 决策记录（单智能体vs多智能体、并发/编排、用户、拓扑结构、HITL、成功指标、MVP外内容）
  • 访谈记录 — 表格：问题、推荐答案、用户回复、锁定决策（追加会话内容）
  • 变更日志 — 每条架构修订记录一行；不得清空
  • 假设条件 — 推断内容，标记
    confirmed
    或
    assumed
  • 功能需求 — 可测试的编号列表，关联到访谈对应行
  • MVP范围 — 包含/排除表
  • 状态 schema 与 错误契约 — 具体结构
  • 实施计划 — 分阶段检查清单
仅针对选中的框架添加额外内容，省略未选中框架的标题，不得添加「N/A」「不适用」这类占位内容。未选中框架的拒绝理由需放在框架推荐 → 备选方案（一句话）中，此内容足够。
框架额外内容（仅选中时包含）
LangGraphMermaid 
flowchart TB
图：包含所有节点，单列主流程，虚线表示错误/中断边；使用与五模块图相同的
classDef
为节点上色；添加简洁的节点→模块图例。布局必须遵循
references/report-template.md
（LangGraph流程图）。禁止：在此流程图中按架构原则模块创建
subgraph
（参考
references/reference-architecture.md
— LangGraph容器与架构原则模块）
CrewAI团队结构表：团队名称、每个团队的智能体数量、流程类型、任务交接方式
文件中始终包含：
  • 智能体角色蓝图：每个智能体的输入、输出、工具、模型、验收标准
  • 推荐工具栈：智能体可调用工具 + 基础设施表
聊天中的约200字内容：不含mermaid图、访谈表格、完整工具栈表。
访谈期间： 记录每个问题、推荐答案、用户回复、锁定决策，用于生成报告文件。

Critical rules

关键规则

  • No framework pick before interview complete
  • Three questions not on whole product — one classification per subtask row
  • Living ADR only 
    docs/specs/agent-architecture.md
    — must include Reference Architecture (colored Mermaid), Trade-off Budget, Architecture Change Signal, Changelog
  • One language: human's opening language. No English headers with other-language cells. Doctrine ids stay English in the Component column and Mermaid first line; not in prose cells or interview sentences
  • Not 
    docs/specs/agent.md
    (behavior; 
    ns-living-spec
    )
  • Reopen this skill only when an architecture decision changes (topology, HITL, MCP contract, change signal). Implementation-only: 
    ns-langgraph-agents
    + 
    graph-spec.md
    ; ADR intact
  • No implementation code unless user asks after report
  • LangGraph node flowchart: 
    subgraph
    per doctrine block (Orchestrator / Model / Gate clusters) = forbidden — paint nodes, do not wrap them
  • Not requirements generation — architecture + agent design only
  • Rich context upfront: lock those branches, skip, start at highest-uncertainty gap
  • 访谈完成前不得选择框架
  • 不得针对整个产品提三个问题——需为每个子任务行单独分类
  • 动态ADR仅能写入
    docs/specs/agent-architecture.md
    — 必须包含参考架构（彩色Mermaid图）、权衡预算、架构变更信号、变更日志
  • 单一语言：采用用户开场语言。不得出现英文表头搭配其他语言单元格的情况。架构原则ID在「组件」列和Mermaid第一行保留英文；不得出现在文案单元格或访谈语句中
  • 不得写入
    docs/specs/agent.md
    （该文件为行为规范，由
    ns-living-spec
    负责）
  • 仅当架构决策变更（拓扑结构、HITL、MCP契约、变更信号）时，才可重新启用该技能。仅涉及实施：使用
    ns-langgraph-agents
    + 
    graph-spec.md
    ；ADR保持不变
  • 除非用户在报告后要求，否则不得生成实施代码
  • LangGraph节点流程图：禁止按架构原则模块（Orchestrator / Model / Gate集群）创建
    subgraph
    — 应为节点上色，而非包裹节点
  • 不得用于需求生成——仅负责架构+智能体设计
  • 若已有丰富上下文：锁定对应分支，跳过相关步骤，从不确定性最高的缺口开始

Reverse mode (agent already built)

逆向模式（智能体已构建完成）

Trigger: "document why this agent is like this", "we never wrote the architecture decisions", or run this skill on existing runtime.
  1. Read runtime: graph nodes/crew tasks, tools, 
    interrupt
    points, conditional routers. Plus 
    docs/context/system-reverse-spec.md
    or 
    brownfield-map.md
    if present, 
    graph-spec.md
    if present.
  2. Draft reference architecture (five blocks) + subtask grid from evidence (
    references/reference-architecture.md
    , 
    references/task-decomposition.md
    — Reverse mode). Every row: 
    source: code | interview
    , 
    status: inferred | confirmed
    .
  3. Grill only what code cannot prove: cost of error, reversibility, real-case coverage, end user, success metric.
  4. Infer trade-off budget + change signal from runtime metrics or defaults. Weak evidence: confirm one line each.
  5. Same Step 8 two-phase close: ~200-word chat first, then 
    docs/specs/agent-architecture.md
    describing what is. Flag contradictions (irreversible action, no gate) under Next Steps and Risks.
触发条件：「梳理该智能体设计的理由」「我们从未记录架构决策」，或对现有运行时执行该技能。
  1. 读取运行时信息：图节点/团队任务、工具、
    interrupt
    点、条件路由。若存在
    docs/context/system-reverse-spec.md
    或
    brownfield-map.md
    、
    graph-spec.md
    也需一并读取。
  2. 根据证据草拟参考架构（五模块）+ 子任务网格（参考
    references/reference-architecture.md
    、
    references/task-decomposition.md
    — 逆向模式）。每行需标记
    source: code | interview
    、
    status: inferred | confirmed
    。
  3. 仅对代码无法证明的内容进行梳理：错误成本、可逆性、实际场景覆盖率、终端用户、成功指标。
  4. 从运行时指标或默认值推断权衡预算+变更信号。若证据不足：每个内容需用户一行确认。
  5. 遵循步骤8的两阶段收尾：先给出约200字的聊天内容，再生成
    docs/specs/agent-architecture.md
    描述当前架构。在「下一步与风险」部分标记矛盾点（如不可逆操作但无网关）。

Related skills (optional — when installed in same project)

关联技能（可选 — 同一项目中已安装时）

  • ns-agent-engineering
    — if conceptual agent vs RAG vs Prompt vs Fine-Tune not locked, run first (
    docs/specs/agent-design.md
    )
  • ns-spec-driven
    — Clarify first if product scope vague
  • ns-spec-driven
    Specify — product requirements after architecture locked
  • ns-docs-writer
    — README / 
    docs/
    link 
    docs/specs/agent-architecture.md
    . Do not rewrite decision record
  • ns-living-spec
    — owns 
    docs/specs/agent.md
    (behavior). Does not overwrite this ADR
  • ns-langgraph-agents
    — grep/Glob skill file. Present: read before LangGraph recommendations (includes JSON-planner operator progress). Implementation after report
  • ns-agent-engineering
    — 若Agent、RAG、Prompt与微调的概念选型未确定，需先执行该技能（参考
    docs/specs/agent-design.md
    ）
  • ns-spec-driven
    — 若产品范围模糊，需先进行澄清
  • ns-spec-driven
    Specify — 架构确定后生成产品需求
  • ns-docs-writer
    — 在README / 
    docs/
    中链接
    docs/specs/agent-architecture.md
    ，不得重写决策记录
  • ns-living-spec
    — 负责
    docs/specs/agent.md
    （行为规范），不得覆盖本ADR
  • ns-langgraph-agents
    — 搜索该技能文件。若存在：在给出LangGraph推荐前先阅读（包含JSON规划器的operator-progress细节），报告完成后进行实施