用 Agent 编排 重写部门边界，
让人专注在判断、品味与关系。
问达科技不是“传统组织 + 一个 AI 部门”。我们用 AI 原生公司的方式组织自己——小团队、高人均杠杆、流程岗转编排岗，把 Agent 当同事一起做事。 这一页讲我们怎么排兵布阵，也是我们建议客户参考的组织设计样板。
五条不可妥协的设计前提
这五条是我们衡量“组织有没有真的 AI 原生”的检查项。 每条都直接影响岗位编制、决策权分配和人均产出。
小团队、高人均杠杆
用 Agent 把单兵作战半径放大，组织规模尽量压在 Dunbar 数(~150)以内。 每多招一个人，先问：这个角色能否被 Agent + 现有员工承担？
全栈优先，角色折叠
研发兼产品、产品兼运营、运营兼数据分析。 Agent 把跨职能的工具门槛抹平，组织自然变扁。
流程岗 → 编排岗
“传话 / 排期 / 汇总”的岗位转为“设计 Agent + 评测 Agent + 兜底人工”。不再有专门“催进度”的人。
决策权下沉
一线员工自带 AI 上下文，具备过去需要中层才能做的判断； 管理层减层，信息差被 Agent 直接抹平。
数据与评测是一等公民
每个业务单元对自己产出的数据 / 评测集负责， 不把数据丢给一个集中“数据部”，数据飞轮才转得起来。
3–15 人阶段的最小可运营骨架
创始期不设“部门”，只设“闭环”。 每个人负责一个闭环加 1–2 个 Agent，脱手可复用，不脱手就是负担。
CEO / 创始人(同时是首席 Agent 使用者与评测负责人)
│
├── 产品与研发闭环(2–6 人) · 全栈 + 设计 + Agent Lead
│ └── 每人负责 1 个主场景 + 1–2 个 Agent 遵从“设计·评测·上线·复盘”
│
├── 增长与客成闭环(1–3 人) · 内容 + 社区 + L1 工单
│ └── 80% 内容 / 跳庇 / FAQ 由 Agent 产出，人做选题与信任
│
├── 模型与平台能力(0–1 人) · 初期不设专职
│ └── 有需要时由 CEO + 资深工程兑现出“平台日”
│
└── 运营与财务(0–1 人) · 多职能合并
└── 凭证 / 报销 / HR / 合同 依赖 Agent + 受控执行
早期不可妥协的三件事
这三件事是创始人不能外包的职责，与人数无关：
30 人量级 AI 原生公司的参考骨架
下面是一个参考骨架，不是规范——具体编制随业务形态变化。 关键看比例分布是否健康，而不是岗位名称。
CEO
├── 产品工程小队 × N(每队 4–7 人，全栈 + 产品 + 设计 + 评测)
│ └── 每队配 1 名 Agent Lead，负责把流程沉淀成 Agent
│
├── 模型与平台组(3–5 人)
│ ├── 模型选型 / 微调 / 推理成本
│ ├── Agent 框架与工具链(MCP / Skills / Eval)
│ └── 数据基础设施(向量库 / 反馈回流 / 标注)
│
├── GTM 小队(3–5 人)
│ ├── 增长 + 内容(大量 AI 辅助生成)
│ └── 客户成功(Agent 处理 L1 工单，人工兜底 L2/L3)
│
└── 运营与合规(1–2 人)
└── 财务 / 法务 / HR 多职能合并，Agent 做 80% 流程
关键比例参考
若运营合规占比膨胀，通常是 Agent 化未跟上；若 GTM 显著超 15%，需要核查是不是产品力不够、靠人力堆增长。
传统岗位如何在 AI 原生形态下被重写
不是把人换掉，而是把"重复执行 + 信息传递"的部分交给 Agent， 让人聚焦在判断、设计与评测上。岗位 title 可以保留，职责必须重写。
写下来 > 开会；Agent 即同事
AI 原生组织的纪律不是"听上去先进"，而是 Agent 能不能消费你产出的内容、能不能被像同事一样管理。
我们怎么协作
- 写下来 > 开会。 文档 / Issue / PR 是 Agent 可消费的一等输入，口头共识不算数。
- Agent 即同事。 有命名、有 owner、有评测分数、有"绩效"复盘，纳入正常组织运营。
- 评审而非审批。 决策走异步评审(文档 + 评论)，减少同步会议。
- 可观测的产出。 每周用 AI 自动汇总人 + Agent 的产出与质量，而不是靠周报自述。
我们刻意避免的反模式
- 设立独立"AI 部"游离在业务外 → 应嵌入每个产品小队。
- Agent 项目无 owner、无评测、无下线机制 → 比僵尸服务更难清理。
- 用人头数衡量组织产出 → 应衡量"人 + Agent"联合产出。
- 把所有数据集中到一个数据团队，业务侧无数据感 → 数据飞轮转不起来。
- 中层只做信息传递，不下场用 AI → 信息差被 Agent 抹平，角色失效。
让 Agent 能动手，但只在 6 条边界之内
受控执行是"AI 能不能动手做财税 / 报销 / 申报"的安全协议。 只要任一条不满足，我们就退回"草稿 + 人工提交"模式，绝不闯关。
六条硬规则
- 人触发。 动作必须由具体的人在飞书 / 工单 / 看板上点击发起，Agent 不主动出手。
- 人登录。 外部系统(税局 / 银行 / SaaS)始终用本人浏览器会话，凭据不离开本机。
- 人复核。 关键字段(金额 / 期间 / 抬头 / 收款方)在提交前必须由人勾选确认。
- 二次确认。 付款 / 申报 / 撤销 等不可逆动作，需要二次签名或独立设备确认。
- 留痕。 每一步截图 / 关键值 / 责任人写入审计日志，可被审计员逐步回放。
- 凭据隔离。 Agent 不持久化任何账号密码，Token 短时、最小权限、按动作发放。
边界落地的做法
- 动作清单白名单。 客户上线哪类受控动作，先在合同与运行手册里逐条列出，默认拒绝其他。
- 双轨提交模式。 关键场景同时支持"Agent 草稿 + 人工提交"与"Agent 受控提交"，一键切换。
- 评测覆盖动作面。 Eval 不只测问答，还要回放真实表单提交流程的成功率与回滚率。
- 反例演练。 定期注入越权 / 误点 / 中断场景，验证 Agent 会停在边界上而不是硬闯。
人数刻度上的组织演进参考
每个阶段的重点不一样。早期重在"全员上手"，规模化时重在"基础设施 + 小队自治"， 跨过 Dunbar 数后必须谨慎扩张，优先把新岗位拆给 Agent。
想用同样的方式重新设计你的组织？
不止做交付，我们也帮客户做 AI 原生组织诊断：岗位画像、协作约定、 Agent 化优先级，产出可落地的 30 / 60 / 90 天行动清单。