AI Agent 生产落地架构:从个人 CLI 到团队平台
个人使用 AI 编程 Agent 时,终端里的一个命令就够了;团队使用时,问题会立刻变成权限、审计、成本、上下文、任务分发和质量门禁。本文给出一套可落地的生产级架构,把 Claude Code、Codex CLI、OpenCode、Hermes Agent 等工具从个人工具升级为团队研发平台。
一、为什么个人用法不能直接搬到团队
个人 CLI 模式的优点是快,但团队场景需要解决 6 类工程问题:
| 问题 | 个人模式表现 | 团队平台需要补齐 |
|---|---|---|
| 权限 | Agent 可直接读写本地仓库 | 按项目、目录、命令、数据类型授权 |
| 审计 | 终端历史零散 | 每次工具调用、diff、审批可追踪 |
| 上下文 | 靠用户临时说明 | 自动构造项目上下文包 |
| 质量 | 用户自己跑测试 | 构建、测试、安全扫描自动闭环 |
| 成本 | 自己感知 Token 消耗 | 按项目、成员、任务统计和限额 |
| 协作 | 一人一会话 | Issue、PR、Chat 与任务状态联动 |
二、生产级总体架构
生产级 Agent 平台可以拆成 6 层:
flowchart LR
A["团队入口: Issue / PR / Chat"] --> B["Agent 工作台"]
B --> C["编排层: Plan / Execute / Verify"]
C --> D["工具层: Shell / Git / DB / Browser"]
B --> E["上下文层: 代码图谱 / RAG / 记忆"]
C --> F["安全层: RBAC / 沙箱 / 审计"]
D --> G["可观测层: 日志 / 轨迹 / 成本"]
F --> G
E --> C2.1 团队入口层
入口层负责把不同来源的请求统一成标准任务:
{
"task_id": "agent-task-2026-0012",
"source": "github_issue",
"project": "billing-service",
"actor": "dev-zhang",
"intent": "修复发票金额四舍五入错误",
"priority": "P1",
"risk_level": "medium",
"target_branch": "main",
"acceptance": [
"新增单元测试覆盖金额边界值",
"npm run test:billing 必须通过",
"不能修改 invoice schema"
]
}2.2 Agent 工作台层
工作台不是聊天窗口,而是任务控制台。它至少要展示:
| 字段 | 说明 |
|---|---|
| Task | 任务标题、来源、优先级、负责人 |
| Context | 传给 Agent 的上下文文件、规则、历史记录 |
| Plan | Agent 拆解出的步骤和风险 |
| Actions | 文件读写、命令执行、浏览器操作、数据库查询 |
| Verification | 测试、构建、Lint、安全扫描结果 |
| Decision | 自动合并、人工审批、退回修改或放弃 |
三、上下文包设计
Agent 的稳定性很大程度取决于上下文包。不要把整个仓库粗暴塞进去,而是分层构造。
context_pack:
project_profile:
framework: "FastAPI + PostgreSQL"
language: "Python 3.11"
test_command: "pytest tests/billing -q"
task_scope:
changed_area:
- "app/billing/"
- "tests/billing/"
forbidden_area:
- "app/auth/"
- "migrations/"
files:
required:
- "app/billing/invoice.py"
- "app/billing/money.py"
- "tests/billing/test_invoice.py"
optional:
- "docs/billing-rules.md"
rules:
- "金额统一使用 Decimal,不允许 float"
- "数据库 schema 变更必须人工审批"
recent_failures:
- "test_rounding_half_up failed on 19.995"参数说明
| 参数 | 类型 | 必填 | 说明 |
|---|---|---|---|
project_profile |
object | 是 | 项目技术栈、测试命令和工程规范 |
task_scope.changed_area |
array | 是 | 允许 Agent 优先搜索和修改的区域 |
task_scope.forbidden_area |
array | 否 | 禁止修改或需要审批的区域 |
files.required |
array | 是 | 必须读取的文件 |
rules |
array | 是 | 任务级硬约束 |
recent_failures |
array | 否 | 最近失败日志或用户反馈 |
四、编排层:Plan、Execute、Verify
编排层的关键不是让 Agent “自由发挥”,而是让它每一步都有边界。
from dataclasses import dataclass
from enum import Enum
class StepType(str, Enum):
READ = "read"
PATCH = "patch"
COMMAND = "command"
VERIFY = "verify"
REPORT = "report"
@dataclass
class AgentStep:
type: StepType
title: str
risk: str
requires_approval: bool = False
def should_require_approval(step: AgentStep) -> bool:
risky_keywords = ["deploy", "migration", "delete", "secret", "production"]
if step.requires_approval:
return True
return any(word in step.title.lower() for word in risky_keywords)
plan = [
AgentStep(StepType.READ, "读取 billing 相关文件", "low"),
AgentStep(StepType.PATCH, "修复 Decimal 四舍五入逻辑", "medium"),
AgentStep(StepType.VERIFY, "运行 pytest tests/billing -q", "low"),
AgentStep(StepType.REPORT, "输出 diff 摘要和测试结果", "low"),
]
for step in plan:
if should_require_approval(step):
print(f"WAIT_APPROVAL: {step.title}")
else:
print(f"RUN: {step.title}")五、安全层:默认拒绝,高风险审批
生产平台的安全策略建议采用“默认拒绝 + 明确授权”:
security_policy:
default: deny
filesystem:
allow_read:
- "app/**"
- "tests/**"
- "docs/**"
allow_write:
- "app/billing/**"
- "tests/billing/**"
deny_write:
- ".env"
- "migrations/**"
- "infra/production/**"
commands:
allow:
- "pytest tests/billing -q"
- "ruff check app/billing tests/billing"
require_approval:
- "git push"
- "docker compose up"
- "alembic upgrade"
deny:
- "rm -rf"
- "curl * | sh"
- "chmod 777"
network:
allow_hosts:
- "api.github.com"
deny_private_network: true六、可观测层:每个任务都要能复盘
一个可复盘的 Agent 任务至少要记录这些事件:
CREATE TABLE agent_events (
id BIGSERIAL PRIMARY KEY,
task_id TEXT NOT NULL,
event_type TEXT NOT NULL,
actor TEXT NOT NULL,
model TEXT,
tool_name TEXT,
input_tokens INTEGER DEFAULT 0,
output_tokens INTEGER DEFAULT 0,
cost_usd NUMERIC(12, 6) DEFAULT 0,
risk_level TEXT DEFAULT 'low',
payload JSONB NOT NULL,
created_at TIMESTAMPTZ NOT NULL DEFAULT now()
);
CREATE INDEX idx_agent_events_task_id ON agent_events(task_id);
CREATE INDEX idx_agent_events_created_at ON agent_events(created_at);关键指标包括:
| 指标 | 解释 | 用途 |
|---|---|---|
| 首次可用结果时间 | 从任务创建到第一个可评审 diff 的时间 | 衡量效率 |
| 自动通过率 | 无人工修正即可通过验证的比例 | 衡量质量 |
| 人工审批次数 | 高风险操作触发审批的次数 | 衡量风险 |
| Token/任务 | 单个任务的平均 Token 消耗 | 成本控制 |
| 回滚率 | Agent 结果被撤销的比例 | 衡量可靠性 |
七、落地路线
第 1 周:个人增强
- 固定项目规则文件
- 统一任务提示词模板
- 要求每次任务输出测试结果和 diff 摘要
第 2-3 周:团队试点
- 接入 Issue 和 PR
- 建立安全策略和审批规则
- 开始记录 Agent 任务日志
第 4-6 周:平台化
- 建立 Agent 工作台
- 接入成本看板
- 将测试、构建、安全扫描作为验证门禁
第 7 周以后:规模化
- 引入多模型路由
- 建立任务模板库
- 沉淀失败案例和上下文包策略
总结
AI Agent 的生产落地不是“给每个人装一个 CLI”,而是把 Agent 纳入工程体系:任务有入口、上下文有结构、执行有边界、结果有验证、过程可审计、成本可观测。只有做到这些,Agent 才能从个人效率工具变成团队研发基础设施。