手把手教你用GPT-5.5写一个能自己改代码、跑测试的Coding Agent

0 阅读3分钟

GPT-5.5 适合做 Coding Agent,不是因为它能生成更长代码,而是因为它能在 Responses API 中结合上下文、工具调用、推理状态和执行反馈,完成更长链路的工程任务。

一个可用的 Coding Agent 至少要能完成:读项目、定位问题、修改文件、运行测试、根据报错继续修复。核心难点不是“让模型动手”,而是让它在权限、日志、停止条件和成本边界内动手。

1. Agent Loop:先定义停止条件

基础流程:

  1. 接收任务,确认目标和限制。
  2. 收集上下文,读取必要文件或搜索文档。
  3. 生成修改计划。
  4. 使用 apply_patch 修改文件。
  5. 使用 shell 执行测试或静态检查。
  6. 根据结果继续修复,直到完成或触发停止条件。

停止条件应写入配置,而不是只写进 prompt:

{
  "maxIterations": 5,
  "maxFilesChanged": 8,
  "testTimeoutSeconds": 180,
  "requireApprovalFor": ["migration", "dependency-install", "delete-file"]
}

原则:prompt 负责描述任务,系统配置负责约束行为。

2. apply_patch:让代码修改可审计

apply_patch 适合让模型以结构化 diff 修改文件。相比整文件覆盖,patch 更容易审查、回滚和定位风险。

建议增加三类限制:

限制类型规则
工作区限制只能修改当前 repo 或指定目录
文件类型限制密钥、生产配置、迁移脚本默认审批
变更规模限制超过文件数或行数阈值先输出计划

模型可以改文件,不代表可以无边界改文件。

3. shell:按风险分级执行命令

shell 让 Agent 获得真实反馈,但也是最高风险工具之一。

风险级别示例策略
低风险npm testpnpm lintgo test ./...pytest可自动执行
中风险安装依赖、生成代码、运行迁移、启动服务需要审批或白名单
高风险删除文件、改系统配置、访问外网、推送代码、操作生产环境默认拒绝

审批日志应记录任务 ID、命令、工作目录、模型输出、执行结果和失败原因。

4. 上下文续接:保留工具调用状态

Coding Agent 最怕“失忆”:上一轮为什么改文件、测试报错是什么、哪个工具调用还没完成。Responses API 的价值在于可以续接状态。

推荐做法:

  • 保留相关 reasoning items。
  • 将工具调用结果带回下一轮。
  • 使用 previous_response_id 做状态续接。
  • 对有合规要求的场景评估 encrypted reasoning items。

这比手工拼接聊天记录更适合长任务。

5. 模型路由:不是每一步都用 GPT-5.5

Agent 步骤推荐能力
需求理解、跨文件设计、复杂 bug 定位GPT-5.5
简单解释、注释生成、格式转换低成本模型
文档搜索web search / file search / MCP
测试执行shell
代码落盘apply_patch

实际落地时,也可以引入像 147AI 这样的模型调度服务来承担调度和管理逻辑,它可以帮助记录每一步所用的模型、上下文规模、shell 重试次数、patch 审批结果和成本开销。借助这类平台,工程师能够持续优化 agent loop 的设计架构,而不用把系统能力绑定在某一个具体模型上。

6. 推荐落地路线

阶段能力范围风险控制
第一阶段只读代码,输出修改建议无自动写入
第二阶段生成 patch,人工确认后应用人工审核
第三阶段自动运行测试高风险命令审批
第四阶段低风险任务自动修复配额、日志、回滚齐全

GPT-5.5 让 Coding Agent 更接近生产可用,但真正决定落地质量的是权限、审计、回滚、评测和成本控制。