软件交付正在从"人写代码、人审代码、人部署"的模式,转向"Agent 生成、Agent 校验、人决策"的协作模式。Endava 这家全球软件工程公司正在把这条路径走通——他们用 ChatGPT Enterprise 和 Codex 作为核心引擎,把 AI Agent 嵌入需求分析、代码生成、测试、部署等环节,目标不是替换工程师,而是让每个环节都有 Agent 协助,工程师把精力集中在判断和架构上。
从工具到 Agent:思维模型的切换
很多团队对 AI 的使用还停留在"工具"层面——打开 ChatGPT 问一段代码,复制粘贴到项目里,结束。Endava 的做法不同:他们把 AI 当作 Agent,即有输入、有上下文、有执行链路的自主单元。一个 Agent 不是只回答一个问题,而是:
- 接收一个任务描述(比如"为这个 REST API 补充集成测试")
- 自行拆解步骤(读现有代码 → 生成测试骨架 → 运行 → 修复失败用例)
- 输出可审查的结果(测试文件 + 运行报告)
这意味着 Agent 需要访问代码仓库、CI 系统和文档,而不是一个孤立的聊天窗口。ChatGPT Enterprise 提供了数据隔离和审计能力,Codex 则提供了代码生成和执行沙箱,两者组合才能支撑真正的 Agent 工作流。
三个关键交付环节的 Agent 化
需求到代码:Codex 作为首稿引擎
Endava 让 Codex 在需求文档和现有代码库的上下文中生成"首稿代码"。工程师的角色从"写第一版"变成"审查和修正第一版"。实际效果:
- 重复性模式代码(CRUD 接口、数据模型映射、配置文件)生成速度提升明显
- 工程师更多时间花在边界条件、异常处理和架构一致性上
- 需要明确约束:Codex 生成的代码必须经过 lint + 单元测试后才进入评审流
测试自动化:Agent 驱动的测试生成与修复
测试是 Agent 最容易产生实际价值的环节。Endava 的做法是让 Agent 读代码 diff,自动生成对应的测试用例,并在 CI 中运行。如果测试失败,Agent 尝试自动修复——修复的不是业务代码,而是测试本身(断言错误、mock 过期等)。
流程编排:多 Agent 协作的工作流
单个 Agent 能处理一个环节,但软件交付是多环节串联的。Endava 正在构建的架构是:一个编排层把多个 Agent 连成流水线——需求 Agent 输出结构化 spec → 代码 Agent 生成实现 → 测试 Agent 校验 → 部署 Agent 生成变更清单。每个环节的输出都是下一个环节的输入,人在关键节点做审批。
实践:搭建一个最小可用的代码审查 Agent
下面用一个可运行的 Python 示例演示如何把 OpenAI API 封装成一个代码审查 Agent。这个 Agent 接收 git diff,输出结构化审查意见,可以直接嵌入 CI 流水线。
#!/usr/bin/env python3
"""
code_review_agent.py — 最小代码审查 Agent
依赖: pip install openai
运行前设置: export OPENAI_API_KEY="sk-..."
用法: python code_review_agent.py <git_diff_file>
"""
import sys
import json
from openai import OpenAI
REVIEW_PROMPT = """你是一个代码审查 Agent。请对以下 git diff 进行审查,输出 JSON 格式的结果。
审查维度:
- 安全性问题(硬编码密钥、SQL 注入风险等)
- 逻辑错误(边界条件、类型不匹配等)
- 可维护性(命名、重复代码、过长函数等)
- 性能(不必要的循环、N+1 查询等)
输出格式(严格 JSON):
{
"summary": "一句话总结",
"issues": [
{
"severity": "high|medium|low",
"category": "security|logic|maintainability|performance",
"file": "文件路径",
"line": "行号或行号范围",
"description": "问题描述",
"suggestion": "修复建议,给出具体代码片段"
}
],
"approved": true或false(是否有 high 级别问题则不批准)
}
git diff:
{diff_content}
"""
def review_diff(diff_path: str) -> dict:
client = OpenAI() # 自动读取 OPENAI_API_KEY 环境变量
with open(diff_path, "r", encoding="utf-8") as f:
diff_content = f.read()
# 限制 diff 大小,避免超出 token 额度
if len(diff_content) > 15000:
diff_content = diff_content[:15000] + "\n... (diff 截断,共 {} 字符)".format(len(diff_content))
response = client.chat.completions.create(
model="gpt-4o",
messages=[
{"role": "system", "content": "你只输出合法 JSON,不输出任何其他文本。"},
{"role": "user", "content": REVIEW_PROMPT.format(diff_content=diff_content)},
],
temperature=0.2, # 低温度保证输出稳定
response_format={"type": "json_object"},
)
result = json.loads(response.choices[0].message.content)
return result
def main():
if len(sys.argv) < 2:
print("用法: python code_review_agent.py <git_diff_file>")
print("生成 diff: git diff HEAD~1 > diff.txt")
sys.exit(1)
diff_path = sys.argv[1]
result = review_diff(diff_path)
# 输出审查结果
print(json.dumps(result, indent=2, ensure_ascii=False))
if not result.get("approved", False):
print("\n⚠️ 审查未通过,存在 high 级别问题,请修复后再提交。")
sys.exit(1)
else:
print("\n✅ 审查通过,可以进入人工复核环节。")
if __name__ == "__main__":
main()
运行步骤:
# 1. 安装依赖
pip install openai
# 2. 设置 API Key(ChatGPT Enterprise 用户使用组织级 Key)
export OPENAI_API_KEY="sk-..."
# 3. 生成最近的代码变更 diff
git diff HEAD~1 > my_diff.txt
# 4. 运行审查 Agent
python code_review_agent.py my_diff.txt
输出是结构化 JSON,可以直接被 CI 系统解析——如果 approved 为 false,流水线自动阻断;如果为 true,进入人工复核。这是把 Agent 从"聊天工具"变成"流水线节点"的关键一步。
嵌入 CI:让 Agent 成为流水线的一环
上面的脚本在本地跑通了,下一步是把它嵌入 CI。以下是一个 GitHub Actions 的最小配置:
# .github/workflows/ai-code-review.yml
name: AI Code Review
on:
pull_request:
types: [opened, synchronize]
jobs:
review:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
with:
fetch-depth: 2 # 需要 HEAD~1 的内容
- name: Install dependencies
run: pip install openai
- name: Generate diff
run: git diff HEAD~1 > diff.txt
- name: Run review agent
env:
OPENAI_API_KEY: ${{ secrets.OPENAI_API_KEY }}
run: python code_review_agent.py diff.txt > review_result.json
- name: Post review comment
if: always()
uses: actions/github-script@v7
with:
script: |
const fs = require('fs');
const result = JSON.parse(fs.readFileSync('review_result.json', 'utf8'));
const body = `## AI 审查结果\n${result.summary}\n\n` +
result.issues.map(i =>
`- **[${i.severity}]** ${i.category}: ${i.description} (${i.file}:${i.line})\n > 建议: ${i.suggestion}`
).join('\n');
github.rest.issues.createComment({
owner: context.repo.owner,
repo: context.repo.repo,
issue_number: context.issue.number,
body: body
});
- name: Check approval
run: |
approved=$(jq '.approved' review_result.json)
if [ "$approved" = "false" ]; then
echo "::error::AI 审查未通过,存在高风险问题"
exit 1
fi
这个配置让每次 PR 自动触发 Agent 审查,审查意见直接贴到 PR 评论里,高风险问题阻断合并。工程师看到的是具体的问题描述和修复建议,而不是一个模糊的"请改进代码质量"。
AI 原生文化的建立:不只是技术问题
Endava 强调"AI-native culture",这背后有几个实操要点:
权限和边界要明确。 Agent 能读哪些代码、能写哪些文件、能调用哪些 API——这些必须用策略文件定义,而不是靠"小心一点"。ChatGPT Enterprise 的数据隔离和 Codex 的沙箱执行提供了基础设施,但团队仍需要自己写准入规则。
审查流程不能省。 Agent 生成的代码和测试必须走同样的评审流程。区别只是评审的对象从"人写的第一版"变成"Agent 生成的第一版",审查标准不降级。
度量要具体。 不要用"AI 提升了效率"这种模糊说法。Endava 建议度量:首稿生成时间、测试覆盖率变化、PR 从提交到合并的平均时长、Agent 审查发现的问题数 vs 人工审查发现的问题数。这些数字才能说明 Agent 到底在哪个环节产生了价值。
落地清单
如果你打算在自己的团队推进类似的 Agent 化交付,可以按这个顺序:
- 选一个环节做试点——测试生成或代码审查是最容易量化效果的起点
- 搭建 Agent 的运行环境——API Key 管理、沙箱、输出格式约束(强制 JSON 输出比自由文本好用得多)
- 嵌入 CI 而不是嵌入聊天窗口——Agent 的价值在自动化流水线里,不在工程师手动复制粘贴里
- 定义准入策略——Agent 能访问什么、不能修改什么、什么级别的问题必须阻断
- 跑两周,收集数据——对比有 Agent 和无 Agent 的环节耗时和错误率
- 逐步扩展环节——从审查扩展到测试生成,再到需求拆解,每个环节独立验证后再串联
Agent 化交付不是一次性改造,而是逐环节替换。先让一个环节跑稳,再连成流水线。Endava 的路径也是这样——从 Codex 生成代码开始,逐步扩展到测试、部署、需求,最终目标是多 Agent 协作的全流程编排,但每个环节都是独立验证后才接入下一步。