当团队开始频繁使用 AI Agent,真正缺的不是更多模型,而是一个能承载任务、上下文、执行轨迹和审批流程的研发工作台。本文从产品结构、数据模型、状态机和接口参数四个角度,设计一个可落地的 Agent 工作台。

Agent 研发工作台设计:任务、上下文、执行记录与人工审批

当团队开始频繁使用 AI Agent,真正缺的不是更多模型,而是一个能承载任务、上下文、执行轨迹和审批流程的研发工作台。本文从产品结构、数据模型、状态机和接口参数四个角度,设计一个可落地的 Agent 工作台。

一、工作台要解决什么问题

一个团队级 Agent 工作台至少要回答 5 个问题:

问题 工作台能力
这个任务要 Agent 做什么 任务卡片、验收标准、风险等级
Agent 看到了什么上下文 上下文包预览、文件列表、规则列表
Agent 做了哪些动作 工具调用时间线、命令输出、文件 diff
是否可以继续执行 风险门禁、人工审批、暂停和恢复
结果是否可信 测试结果、构建结果、安全扫描、Review 结论

二、页面结构设计

工作台可以拆成左右两栏:

mermaid
flowchart TB
  A["任务列表"] --> B["任务详情"]
  B --> C["上下文包"]
  B --> D["执行时间线"]
  B --> E["验证结果"]
  B --> F["审批面板"]
  D --> G["工具调用详情"]
  E --> H["测试报告 / 构建日志 / 安全扫描"]

2.1 核心视图

视图 内容 使用者
Queue 待执行、执行中、待审批、已完成任务 Tech Lead、开发者
Task Detail 任务目标、验收标准、上下文包 开发者
Timeline Agent 的计划、工具调用、命令输出 开发者、Reviewer
Diff Review 文件变更、风险提示、测试结果 Reviewer
Approval 高风险动作确认、拒绝、补充说明 有权限的人
Metrics 通过率、成本、耗时、失败原因 管理者

三、任务状态机

工作台最重要的是状态机。没有状态机,Agent 执行就会变成不可控的聊天记录。

mermaid
stateDiagram-v2
  [*] --> Draft
  Draft --> Ready: context_pack_ready
  Ready --> Planning: start
  Planning --> WaitingApproval: risky_plan
  WaitingApproval --> Executing: approved
  WaitingApproval --> Rejected: rejected
  Planning --> Executing: safe_plan
  Executing --> Verifying: patch_created
  Verifying --> WaitingApproval: risky_result
  Verifying --> Completed: checks_passed
  Verifying --> Failed: checks_failed
  Failed --> Ready: retry
  Completed --> [*]

状态参数说明

状态 进入条件 允许操作
Draft 用户创建任务但上下文未完成 编辑任务、补充验收标准
Ready 上下文包生成完成 开始执行、重新生成上下文
Planning Agent 正在生成计划 暂停、取消
WaitingApproval 存在高风险步骤 批准、拒绝、要求改计划
Executing Agent 正在改文件或调用工具 暂停、终止
Verifying 正在运行测试和扫描 查看日志
Completed 验证通过并生成报告 创建 PR、归档
Failed 执行或验证失败 重试、人工接管

四、数据模型

4.1 任务表

sql
CREATE TABLE agent_tasks (
  id TEXT PRIMARY KEY,
  project_key TEXT NOT NULL,
  source_type TEXT NOT NULL,
  source_url TEXT,
  title TEXT NOT NULL,
  instruction TEXT NOT NULL,
  status TEXT NOT NULL DEFAULT 'draft',
  priority TEXT NOT NULL DEFAULT 'P2',
  risk_level TEXT NOT NULL DEFAULT 'medium',
  created_by TEXT NOT NULL,
  assigned_agent TEXT,
  target_branch TEXT,
  acceptance JSONB NOT NULL DEFAULT '[]',
  created_at TIMESTAMPTZ NOT NULL DEFAULT now(),
  updated_at TIMESTAMPTZ NOT NULL DEFAULT now()
);

4.2 执行事件表

sql
CREATE TABLE agent_task_events (
  id BIGSERIAL PRIMARY KEY,
  task_id TEXT NOT NULL REFERENCES agent_tasks(id),
  event_type TEXT NOT NULL,
  title TEXT NOT NULL,
  detail JSONB NOT NULL DEFAULT '{}',
  risk_level TEXT NOT NULL DEFAULT 'low',
  created_by TEXT NOT NULL DEFAULT 'agent',
  created_at TIMESTAMPTZ NOT NULL DEFAULT now()
);

五、API 设计

5.1 创建任务

http
POST /api/agent/tasks
Content-Type: application/json
json
{
  "project_key": "payment-api",
  "source_type": "manual",
  "title": "修复退款状态没有同步到订单的问题",
  "instruction": "定位 refund succeeded 后 order.status 没有变成 refunded 的原因,并补充回归测试。",
  "priority": "P1",
  "target_branch": "main",
  "acceptance": [
    "新增 refund success 的回归测试",
    "pytest tests/payment -q 通过",
    "不能修改支付网关回调签名逻辑"
  ]
}
参数 类型 必填 说明
project_key string 项目标识
source_type string manualgithub_issuepull_requestchat
instruction string 给 Agent 的任务描述
priority string P0P1P2P3
target_branch string 默认从项目配置读取
acceptance array 验收标准,必须可验证

5.2 审批高风险动作

http
POST /api/agent/tasks/{task_id}/approvals
Content-Type: application/json
json
{
  "event_id": 921,
  "decision": "approved",
  "reason": "允许在测试环境执行数据库迁移 dry-run,不允许连接生产库。",
  "scope_override": {
    "allowed_commands": ["alembic upgrade head --sql"],
    "expires_in_minutes": 30
  }
}

六、前端组件示例

下面是一个精简的 Vue 任务状态组件:

vue
<template>
  <section class="task-panel">
    <header>
      <h2>{{ task.title }}</h2>
      <span :class="['status', task.status]">{{ task.status }}</span>
    </header>

    <ol class="timeline">
      <li v-for="event in events" :key="event.id">
        <strong>{{ event.title }}</strong>
        <span>{{ event.event_type }}</span>
        <button
          v-if="event.event_type === 'approval_required'"
          @click="$emit('approve', event)"
        >
          审批
        </button>
      </li>
    </ol>
  </section>
</template>

<script setup>
defineProps({
  task: { type: Object, required: true },
  events: { type: Array, default: () => [] }
})

defineEmits(['approve'])
</script>

七、审批策略

审批不是所有动作都弹窗,否则团队很快会疲劳。推荐只拦截这几类动作:

动作 风险 默认策略
修改生产配置 必须审批
执行数据库迁移 dry-run 可自动,真实执行审批
删除文件或目录 中高 超过 3 个文件审批
外发代码或日志 必须审批
创建 PR 可自动,但必须附验证报告
运行测试 自动允许

八、落地检查清单

  • 任务必须有明确验收标准
  • 上下文包必须可预览
  • 每次工具调用必须入库
  • 高风险动作必须进入审批状态
  • 失败任务必须保留现场
  • 完成任务必须包含 diff、测试结果和成本摘要

总结

Agent 工作台的核心价值不是“把聊天搬到网页上”,而是把 Agent 执行变成可管理的工程过程。任务、上下文、执行记录、验证结果和人工审批连接起来,团队才敢把更多真实研发任务交给 Agent。