技能介绍

要解决什么问题

单人用大模型写项目时，需求、设计、实现、测试往往混在同一段对话里，字段命名漂移、需求未澄清就开工、Review 形同虚设。天枢（TianShu）把软件交付拆成 18 个职责固定的 Agent，用 三种工作流（链式 / 混合 / 事件驱动）和 三级门禁 约束协作顺序与质量，而不是靠一句「帮我做个 XXX」端到端猜。

框架如何工作

选工作流：按规模调用对应 Skill——小型用 tianshu-chain-workflow（6 个核心 Agent），中型用 tianshu-hybrid-workflow（6+6），大型用 tianshu-event-workflow（全部 18 个）。

核心六 Agent（每个项目必备）：需求理解 tianshu-requirement-agent → 系统设计 tianshu-design-agent → 执行开发 tianshu-dev-agent → 测试验证 tianshu-test-agent → 质量审计 tianshu-audit-agent → 调度协调 tianshu-scheduler-agent。扩展 Agent（UI/UX、前后端、数据库、安全、部署、文档、代码审查、PM、ML、Agent 开发、事件总线）按项目激活。

门禁：通过型（机器自动）→ 确认型（人工确认）→ 交付型（验收）。会话协议（R1–R9）要求需求澄清确认、规则前置、记忆隔离、三维 Review（自审 + 测试 + 代码审查）、修复总结与向量复用等；Agent 间传递需符合 communication-protocol 与标准模板。

典型路径：选工作流 → Invoke tianshu-requirement-agent 做需求 → 按工作流文档依次调用 Agent。

适用边界与红线

信息缺失率 >30% 或关键字段为空时，必须先澄清并人工确认（R1），不能猜需求。
字段命名一致、不绕过门禁、不让 Agent 越权干非本职、信息传递格式完整——文档中的五条红线必须遵守。
链式模式适合脚本/原型（约 1–2 周）；企业级长周期项目应对应事件驱动模式。详细检查点见 references/workflows/ 与各 Agent 定义。