Agent 研发工作台设计:任务、上下文、执行记录与人工审批
当团队开始频繁使用 AI Agent,真正缺的不是更多模型,而是一个能承载任务、上下文、执行轨迹和审批流程的研发工作台。本文从产品结构、数据模型、状态机和接口参数四个角度,设计一个可落地的 Agent 工作台。
一、工作台要解决什么问题
一个团队级 Agent 工作台至少要回答 5 个问题:
| 问题 | 工作台能力 |
|---|---|
| 这个任务要 Agent 做什么 | 任务卡片、验收标准、风险等级 |
| Agent 看到了什么上下文 | 上下文包预览、文件列表、规则列表 |
| Agent 做了哪些动作 | 工具调用时间线、命令输出、文件 diff |
| 是否可以继续执行 | 风险门禁、人工审批、暂停和恢复 |
| 结果是否可信 | 测试结果、构建结果、安全扫描、Review 结论 |
二、页面结构设计
工作台可以拆成左右两栏:
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 执行就会变成不可控的聊天记录。
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 任务表
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 执行事件表
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 创建任务
POST /api/agent/tasks
Content-Type: application/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 | 是 | manual、github_issue、pull_request、chat |
instruction |
string | 是 | 给 Agent 的任务描述 |
priority |
string | 否 | P0、P1、P2、P3 |
target_branch |
string | 否 | 默认从项目配置读取 |
acceptance |
array | 是 | 验收标准,必须可验证 |
5.2 审批高风险动作
POST /api/agent/tasks/{task_id}/approvals
Content-Type: application/json{
"event_id": 921,
"decision": "approved",
"reason": "允许在测试环境执行数据库迁移 dry-run,不允许连接生产库。",
"scope_override": {
"allowed_commands": ["alembic upgrade head --sql"],
"expires_in_minutes": 30
}
}六、前端组件示例
下面是一个精简的 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。