GPT-5.5 适合做 Coding Agent,不是因为它能生成更长代码,而是因为它能在 Responses API 中结合上下文、工具调用、推理状态和执行反馈,完成更长链路的工程任务。
一个可用的 Coding Agent 至少要能完成:读项目、定位问题、修改文件、运行测试、根据报错继续修复。核心难点不是“让模型动手”,而是让它在权限、日志、停止条件和成本边界内动手。
1. Agent Loop:先定义停止条件
基础流程:
- 接收任务,确认目标和限制。
- 收集上下文,读取必要文件或搜索文档。
- 生成修改计划。
- 使用
apply_patch修改文件。 - 使用
shell执行测试或静态检查。 - 根据结果继续修复,直到完成或触发停止条件。
停止条件应写入配置,而不是只写进 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 test、pnpm lint、go 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 更接近生产可用,但真正决定落地质量的是权限、审计、回滚、评测和成本控制。