外观
1 人 + N Agent：面向产品的智能组织范式
这不是一篇“未来公司”想象，而是从三类系统逐步推出来的工程模型：AI Town 的持续世界、MiroFish 的群体与图谱、戏剧工坊的导演-角色协同。它最终指向的不是短剧，而是产品研发组织。
1. 推导链
三篇来源分别解决了三个问题：
| 来源 | 它解决的问题 | 留下的设计 |
|---|---|---|
| AI Town | 角色如何在持续状态里活动 | 服务端事实、时间推进、角色记忆 |
| MiroFish | 多个角色如何围绕同一事件产生反应 | 图谱、事件、关系和信息边界 |
| 戏剧工坊 | 角色如何在导演调度下协同演出 | 调度、角色职责、反应、旁白、收尾 |
把这三个部分迁移到产品研发后，得到的不是“更多 AI 聊天”，而是一套组织模型：
text
1 个决策者
+
N 个岗位 Agent
+
任务图
+
产物库
+
确定性门禁
+
可追溯记忆2. 为什么多 Agent 不能只是一个群聊
一个群聊可以让很多模型同时发表意见，但它没有自动解决以下问题：
text
谁负责？
谁可以修改？
哪份文件是正式版本？
什么条件算完成？
失败以后谁返工？
谁批准进入下一阶段？| 群聊式协作 | 产品组织式协作 |
|---|---|
| 消息是主要产物 | 文件、代码、报告是产物 |
| 角色靠 prompt 区分 | 角色有权限与交付契约 |
| “完成”由模型自述 | “完成”由门禁证明 |
| 上下文越积越长 | 状态写入结构化账本 |
| 讨论可以无限延长 | 任务有依赖、超时和出口 |
Agent 组织的最小单位不是一条消息，而是一项带验收条件的任务。
3. 组织总图
这张图里，人不负责每一步执行。人的位置是：
text
确定目标 → 冻结关键决策 → 处理不可验证的取舍 → 批准发布Agent 负责：
text
调研、拆解、设计、实现、检查、记录、返工、汇报4. 角色不是人设，而是岗位契约
戏剧工坊里，角色有秘密、目标和说话方式。产品 Agent 还需要增加：
yaml
name: linux-driver-agent
role: 负责设备树和 Linux 驱动
inputs:
- frozen_requirements
- hardware_pinmap
- module_contract
can_read:
- requirements/*
- architecture/*
- hardware/pinmap.csv
can_write:
- linux/dts/*
- linux/driver/*
must_produce:
- dts.patch
- driver.patch
- build.log
- test-report.md
gates:
- dtc_compile
- cross_compile
- unit_test岗位契约的五个字段
| 字段 | 回答的问题 |
|---|---|
| 输入 | 这个 Agent 可以依据什么工作？ |
| 权限 | 它可以读、改、执行什么？ |
| 产物 | 它必须交付什么文件？ |
| 门禁 | 什么条件下算通过？ |
| 边界 | 哪些决策必须交给人或上游角色？ |
人设让 Agent 更像一个人，岗位契约让它成为一个可用的岗位。
5. 调度：从导演循环到任务 DAG
戏剧工坊的导演每一集决定下一拍。产品研发不能完全照搬，因为产品任务有并行依赖：
调度器每次只做三类判断：
| 状态 | 调度行为 |
|---|---|
| 依赖未完成 | 不启动，显示阻塞原因 |
| 依赖满足 | 分配 Agent、锁定产物目录 |
| 产物提交 | 运行门禁，决定通过或返工 |
因此可以把两种调度方式分开：
| 场景 | 调度方式 |
|---|---|
| 戏剧 | 导演按冲突和角色压力安排下一拍 |
| 产品研发 | 调度器按依赖和门禁安排下一任务 |
它们可以共享记忆、角色和审查机制，但不能用同一个状态机硬套。
6. 产物必须是一等公民
产品协作的基本记录不是聊天，而是 Artifact：
json
{
"artifact_id": "artifact_20261022_0042",
"type": "architecture",
"path": "architecture/system.md",
"version": 3,
"created_by": "system-architect-agent",
"based_on": ["prd-17", "hardware-pinmap-04"],
"status": "review_pending",
"sha256": "...",
"checks": ["traceability:pass", "interface:pass"]
}产物生命周期
text
working
↓ submit
review_pending
├─ reject → working
└─ approve
↓ gate
verified
↓ 人审批
accepted / released这套做法来自戏剧工坊的剧本/分镜导出，但在产品研发里需要更严格：
- 每份架构必须对应需求来源；
- 每段代码必须对应模块契约；
- 每份测试报告必须对应测试版本；
- 每次发布必须绑定通过过的产物摘要。
7. 门禁比模型能力更重要
Agent 可以写初稿，但不能自己宣布“正确”。
软件产品
text
需求 → 测试用例 → 实现 → 编译 → 单元测试 → 集成测试 → 发布机器人和嵌入式产品
text
需求
↓
器件与电源预算
↓
引脚分配 / 总线协议
↓
设备树 / MCU 配置
↓
驱动 / 应用 / 测试工具
↓
交叉编译
↓
回环 / HIL / 整机测试
↓
烧录与验收| 门禁 | 检查方式 | 适合自动化吗 |
|---|---|---|
| 引脚冲突 | 表格规则 | 是 |
| 电源预算 | 计算 | 是 |
| DTS 语法 | dtc | 是 |
| 固件编译 | 工具链 | 是 |
| 协议回环 | 测试程序 | 是 |
| 代码质量 | 静态检查 + 评审 | 部分 |
| 产品方向 | 人的判断 | 否 |
| 机械安全 | 实机/HIL | 部分 |
Agent 组织的可靠性，取决于它能不能被机器拒绝。
这也是为什么机器人和嵌入式产品特别适合建立 Agent 协作：许多结果可以通过编译、测量、回环和整机验收判断，而不是靠模型自评。
8. 记忆与权限：共享知识不等于全知
AI Town 使用向量记忆回答“哪些历史内容和现在相似”；MiroFish 使用图谱记录实体、关系和事件；戏剧工坊进一步把“谁在场、谁知道什么”做成了显式关系。
产品组织可以沿用同样的模型：
text
Agent ──[:CAN_READ]──> Artifact
Agent ──[:CREATED]────> Artifact
Decision ──[:BASED_ON]─> Artifact
Task ──[:BLOCKED_BY]───> Gate三类记忆
| 记忆 | 内容 | 边界 |
|---|---|---|
| 个人工作记忆 | 当前任务、最近结果、未解决问题 | 只给执行 Agent |
| 项目事实 | 已确认接口、约束、测试结果 | 按项目授权 |
| 决策账本 | ADR、取舍、审批与版本 | 对相关角色可读 |
共享记忆的目标不是让所有 Agent 全知，而是让信息可追溯、可授权、可撤回。
9. 人的审批边界
人不应审批每一行代码，也不能完全退出循环。
| 阶段 | 人的职责 |
|---|---|
| 方向 | 选目标、定优先级、接受市场风险 |
| 需求 | 冻结范围与验收标准 |
| 架构 | 处理不可逆的技术取舍 |
| 实现 | 查看异常、处理阻塞，不逐行代劳 |
| 高风险操作 | 烧录、发布、删除、外部发送必须确认 |
| 里程碑 | 判断是否进入下一阶段 |
text
人审批“要不要做、接受什么风险”
Agent 负责“怎么做、如何验证、如何留下证据”这比“一个人管理一群 AI 员工”更准确：人是边界与决策的所有者，不是所有工作的瓶颈。
10. 一个可落地的产品闭环
第一阶段不应该做“完整 AI 公司”，而应该选一个小模块跑通：
text
需求 Agent → 实现 Agent → 评审 Agent → 编译 / 测试门禁只有这个闭环真实通过，才值得继续增加调研、架构、项目管理和跨节点 Agent。
11. 边界：哪些事情不适合交给 Agent
- 产品是否值得做；
- 客户真正愿意付钱的需求是什么；
- 安全风险是否可以接受；
- 供应链是否可靠；
- 机械动作是否可能伤人；
- 是否烧录生产设备；
- 是否发布给客户；
- 是否删除不可恢复数据。
这些任务可以由 Agent 做资料整理和方案比较，但最终需要人确认。
12. 结论
1 人 + N Agent 不是“让一个人拥有很多聊天机器人”，而是建立一套新的产品协作结构：
text
一个人负责目标、约束、取舍和审批
N 个 Agent 负责岗位工作
任务 DAG 负责调度
产物库负责交付
门禁负责验证
记忆图谱负责来源与权限它从 AI Town 学到持续状态，从 MiroFish 学到事件和图谱，从戏剧工坊学到角色协同；真正迁移到产品研发后，最重要的变化不是 Agent 变多，而是：
每个 Agent 都必须有清楚的职责、可检查的产物和明确的退出条件。