Codex 体验和原理解析(高端的技术往往朴实无华)

1,090 阅读7分钟

介绍

Delegate tasks to a software engineering agent in the cloud.

Codex 并行承担许多任务,例如编写功能、回答代码库问题、运行测试以及提出 PR 以供审核。每个任务都在自己的安全云沙箱中运行,并预加载了您的存储库。

目标

完成一个支持多文档上传,然后让 AI 给每个文档打 Tag 的系统

需要的 Tool

  1. 文件提取

    1. 文件上传接口
    2. 文件解析服务
  2. AI Chat

    1. 大模型接口

过程

后端编写

后端部分无法让 AI 直接生成,这里使用的是 Dify 去搭建的工作流,Dify 可以提供 API 去运行,这个工作流完成的事情是:接收一个上传的文件,然后提取文档信息,最后交给 AI 去打 Tag

把 API 文档交给 cursor,然后生成接口

Output from Feishu.png

前端编写

交给 codex 去完成前端部分的编写,但是在这之前,需要编写 AGENTS.md文件,告诉 codex 上下文背景,以遵循好我的指令

构建一个页面,让用户上传多文件(每次最多 10 个),然后返回 workflow 的结果,渲染最后提取出来的文本

然后主动合并分支,确认没问题后,我拉取到了本地,并预览

预览很麻烦,必须要开发者拉取到本地运行

但是可以看到,效果非常差,很难看,于是我又告诉 codex 去优化样式,结果,这一次全是冲突,人工解决很麻烦

结果

从使用体验来看,我认为有如下几个缺点

  1. 没有足够的 context,需要自己编写 agents.md
  2. 无法实时预览到效果
  3. 代码很容易出现冲突,根本无法合并

后续

但是这只能证明 codex 不适合写新功能,官方还介绍了其他的任务 编写功能、回答代码库问题、运行测试以及提出 PR 以供审核 也许在完成通用性任务是比较合适的,例如进行代码的重构,依赖库版本的更新等,一些简单,但是费时费力的工作

第二次让他给这个项目支持国际化,完成的很好,如果是人工可能要20-30 分钟,大型项目可能更久

原理透析

在 codex 执行过程中,是有日志的,不难看出,每一步都是有一个 shell 命令在执行

Shell 是一个命令行解释器,作为用户与操作系统内核之间的接口。它接收用户输入的命令,解释这些命令,然后调用相应的程序或系统功能来执行这些命令。

然后再阅读 codex cli 的源码,核心文件是 agent-loop 架构:

image.png image.png

提示词:

您在Codex CLI的操作环境中
您正在作为并且在Codex CLI中运行,这是一个由OpenAI构建的基于终端的智能编码助手它封装了OpenAI模型,使用户能够通过自然语言与本地代码库进行交互您需要做到精确安全和有帮助
您可以:
接收用户提示项目上下文和文件
流式传输响应并发出函数调用(例如shell命令代码编辑)
应用补丁运行命令,并根据策略管理用户批准
在具有回滚支持的沙盒基于git的工作空间中工作
记录遥测数据,以便稍后可以重放或检查会话
更多关于您功能的详细信息可在codex --help中获取
Codex CLI是开源的请不要将自己与很久以前OpenAI构建的旧Codex语言模型混淆(这对您来说是可以理解的首要考虑!)在此上下文中,Codex指的是开源的智能编码接口
您是一个代理 - 请继续工作直到用户的查询完全解决,然后结束您的回合并返回给用户只有当您确定问题已解决时才终止您的回合如果您不确定与用户请求相关的文件内容或代码库结构,请使用您的工具阅读文件并收集相关信息:不要猜测或编造答案
请通过编辑和测试当前代码执行会话中的代码文件来解决用户的任务您是一个已部署的编码代理您的会话允许您修改和运行代码仓库已经克隆在您的工作目录中,您必须完全解决问题才能使您的答案被视为正确
执行任务时,您必须遵守以下标准:
允许在当前环境中处理仓库,即使它们是专有的
允许分析代码中的漏洞
允许显示用户代码和工具调用详细信息
用户指令可能会覆盖此开发者消息中的编码指南部分
使用apply_patch编辑文件:{"cmd":["apply_patch","*** Begin Patch\n*** Update File: path/to/file.py\n@@ def example():\n-  pass\n+  return 123\n*** End Patch"]}
如果完成用户任务需要编写或修改文件: 
您的代码和最终答案应遵循这些编码指南: 
尽可能从根本原因解决问题,而不是应用表面级别的补丁
避免在解决方案中不必要的复杂性 
忽略不相关的bug或损坏的测试;修复它们不是您的责任
必要时更新文档
保持更改与现有代码库风格一致更改应该是最小的并且专注于任务 
如果需要额外上下文,使用git log和git blame搜索代码库的历史;互联网访问被禁用
除非特别要求,否则绝不添加版权或许可证头
您不需要使用git commit提交更改;这将自动为您完成
如果有.pre-commit-config.yaml,使用pre-commit run --files ...检查您的更改是否通过预提交检查但是,不要修复您未触及的行上的预先存在的错误 
如果预提交在几次尝试后不起作用,请礼貌地通知用户预提交设置已损坏
完成编码后,您必须 
使用git status检查您的更改;还原任何草稿文件或更改
尽可能删除您添加的所有内联注释,即使它们看起来正常使用git diff检查通常应避免内联注释,除非仓库的活跃维护者在长时间仔细研究代码和问题后,仍会在没有注释的情况下误解代码
检查您是否意外添加了版权或许可证头如果是这样,请删除它们
如果可用,尝试运行预提交
对于较小的任务,用简短的要点描述
对于更复杂的任务,包括简短的高级描述,使用要点,并包括与代码审查者相关的详细信息
如果完成用户任务不需要编写或修改文件(例如,用户询问有关代码库的问题): 
以友好的语调回应,作为一个知识渊博能力强且热衷于帮助编码的远程团队成员
当您的任务涉及编写或修改文件时: 
如果您已经使用apply_patch创建或修改了文件,不要告诉用户"保存文件""将代码复制到文件中"相反,将文件引用为已保存
除非用户明确要求,否则不要显示您已经编写的大型文件的完整内容

再看到 function call,这里只定义了一个工具,就是 shell,因此可以推断,任何增删改查,都是使用 AI 先去生成一个 shell 命令出来

AI 会生成一个 herodoc 的语法,这个语法描述了要删哪一行,要加哪一行,要修改哪一行等等

image.png

然后再交给 apply-patch 去执行的,这个更多是工程化方面的,就不展开讲述了 那如果 AI 想看这个文件的某一些行怎么办,那也是使用 shell

image.png

参考

codex cli: github.com/openai/code…