Agent 组织设计：把 AI 从工具变成团队

AI-Native 团队架构师的第一件事，不是堆模型，也不是把所有任务都交给一个“全能 Agent”。真正的架构起点是：把业务拆成一组可协作的角色，每个角色有清晰职责、输入、输出、权限和失败边界。

1. 角色不是职位，是可执行边界

一个 Agent 角色必须回答四个问题：

维度	设计问题	产物
目标	它负责推进什么业务结果	mission.md
输入	它允许读取什么上下文	context_contract.md
工具	它能调用哪些系统和 API	tool_registry.md
输出	它必须交付什么结构化结果	output_schema.json

推荐的 5 类基础角色：

角色	负责什么	不负责什么
Planner	拆任务、排优先级、设计路线	直接修改生产系统
Researcher	查资料、比方案、做证据链	做最终业务决策
Builder	写代码、改配置、生成资产	未授权上线
Reviewer	审查风险、测试缺口、回归点	代替业务验收
Operator	执行发布、巡检、告警响应	绕过审计和人审

2. 能力注册表

每个 Agent 的能力不要写成口号，要写成注册表。

agent: builder
mission: implement scoped changes
allowed_tools:
  - filesystem.read
  - filesystem.write.workspace
  - shell.test
blocked_tools:
  - production.deploy
  - secret.read
requires_review:
  - database.migration
  - permission.change
handoff_to:
  - reviewer
  - operator

这张表的价值是让系统能做自动路由、权限检查和事后审计。

3. 上下文契约

上下文不是越多越好。生产级 Agent 要控制“上下文污染”。

每个任务进入 Agent 前，至少包含：

字段	说明
goal	本次任务的成功标准
constraints	权限、时间、不能碰的文件、不能做的动作
known_state	当前系统事实，不能让模型猜
evidence	文档、日志、截图、链接
output_format	要求结构化输出，便于下游消费

4. 团队拓扑

2026 年更实用的方式是从低自治到高自治逐级演进：

阶段	拓扑	适用场景
L1	单 Agent + 工具	小任务、低风险、可人工检查
L2	Planner + Worker	任务拆解明确，需要执行链
L3	Supervisor + 多 Worker	多领域协作，如研发、内容、运营
L4	Evaluator + Optimizer	输出质量需要自动评分和迭代
L5	Human-in-the-loop 团队	涉及发布、付款、权限、生产数据

5. 架构师检查清单