AI Agent 实战：ChatGPT、Codex、DeepSeek 工具选型与环境配置指南

1. 从零散工具到工作流：AI Agent 到底在解决什么问题

这两年我断断续续把 AI Agent 塞进了自己的日常开发流程里，从最早拿 ChatGPT 当高级搜索引擎用，到后来用 Codex 这类命令行工具直接改代码，再到现在把 DeepSeek 接进本地脚本做批处理，踩过的坑比写过的代码还多。这篇文章不打算讲什么宏大叙事，就是把我在实际使用中攒下来的一些小经验摊开聊聊，包括工具怎么选、环境怎么配、任务怎么拆、出错了怎么排查。如果你刚开始接触 AI Agent，或者已经用了一阵子但总觉得哪里不顺手，那这些内容应该能帮你省下不少折腾的时间。

先说清楚一个概念上的事。很多人把 AI Agent 和聊天机器人混为一谈，其实差别挺大的。聊天机器人是你问一句它答一句，主动权在你手里；而 Agent 的核心在于它能自己规划步骤、调用工具、根据中间结果调整策略。举个例子，你让 ChatGPT 帮你写个排序算法，它直接给你一段代码就完事了；但如果你让一个 Agent 去“把这个项目里的所有 console.log 清理掉并跑通测试”，它需要先扫描文件、识别目标、逐个修改、运行测试、发现失败再回滚或修正。这个过程中它自主决策的成分越多，就越接近真正的 Agent。

我最初接触 AI Agent 是从 ChatGPT 开始的，那时候主要用它来查 API 文档、解释报错信息。后来发现 Codex 这种命令行工具更适合我这种习惯在终端里干活的人，它能直接读取项目文件、执行命令、修改代码，省去了复制粘贴的麻烦。再后来 DeepSeek 出来了，推理能力不错，价格也友好，我就把它接进了自己的脚本里做一些批量处理的任务。Git 在这个过程中扮演的是版本控制的角色，每次让 Agent 改完代码，我都会先 commit 一下，万一改崩了还能回滚。

提示：不要一上来就追求全自动。先把 Agent 当成一个能力更强但需要监督的实习生，你给它派活、检查结果、纠正错误，等磨合好了再逐步放权。

适合读这篇文章的人大概有这么几类：一是刚听说 AI Agent 想试试但不知道从哪下手的新手；二是已经在用 ChatGPT 或 Codex 但遇到各种报错不知道怎么解决的；三是想把 Agent 集成到自己工作流里的开发者。我会尽量把每个环节的操作步骤和背后的逻辑都讲清楚，让你不仅能照着做，还能理解为什么这么做。

2. 工具选型：ChatGPT、Codex、DeepSeek 各自适合什么场景

2.1 ChatGPT：通用对话与知识问答的首选

ChatGPT 是我用得最久的工具，它的优势在于通用性强、知识面广、对话体验流畅。日常查资料、解释概念、写文档草稿这些任务，它基本都能胜任。我经常用它来快速了解一个不熟悉的库或框架，比如“FastAPI 的依赖注入怎么用”这种问题，它能给出比较完整的示例和解释。

但 ChatGPT 也有明显的短板。一是它不能直接访问你的本地文件系统，你得手动把代码贴进去；二是它的上下文窗口虽然一直在扩大，但处理大型项目时还是容易丢失细节；三是网络问题，国内访问有时候不太稳定，会出现一直在重新连接的情况。我遇到过一次 ChatGPT 无法加载 config.toml 导致对话无法继续的问题，后来发现是配置文件里的 model 字段写错了，修正之后就正常了。

注意：如果你在使用 ChatGPT 时遇到“无法加载 config.toml”之类的报错，先检查配置文件里的 model 名称是否正确，大小写和连字符都要对上。

2.2 Codex：命令行里的代码修改利器

Codex 是 OpenAI 推出的命令行编码 Agent，它的定位很明确：在终端里帮你改代码。我第一次用的时候还挺惊艳的，它能直接读取项目目录、理解代码结构、执行修改命令，整个过程不需要你离开终端。安装方式也不复杂，通过 npm 或者直接下载二进制包都行。

Codex 的使用流程大概是这样的：你先用codex命令启动，然后它会提示你登录。登录方式有两种，一种是用 ChatGPT 账号，一种是用 API Key。我用的是 ChatGPT 账号登录，因为这样不需要额外付费。登录成功后会进入一个交互式界面，你可以直接用自然语言描述你想做什么，比如“把 src/utils 目录下所有文件的 var 改成 const”，它就会去执行。

不过 Codex 也有一些限制。比如它默认只能访问当前工作目录下的文件，如果你想让它处理其他目录的内容，需要手动指定路径。另外，有些模型在 Codex 里是不支持的，我遇到过“the ‘gpt-6.1-sol’ model is not supported when using codex with a chatgpt acc”这样的报错，意思是你用 ChatGPT 账号登录时不能用某些特定模型。解决办法要么换成 API Key 登录，要么换一个支持的模型。

2.3 DeepSeek：性价比高的推理与批处理选择

DeepSeek 是我最近半年用得比较多的工具，主要原因是它的推理能力不错，而且 API 价格相对友好。我一般把它用在两个场景：一是需要深度推理的任务，比如复杂的代码逻辑分析；二是批量处理，比如一次性让它对几十个文件做代码审查。

DeepSeek 的部署方式比较灵活，你可以直接用官方 API，也可以在本地部署。本地部署对硬件有要求，但好处是数据不出本地，适合处理敏感内容。我用的是官方 API，接入方式跟 OpenAI 的接口基本兼容，所以如果你已经有基于 OpenAI SDK 写的脚本，改一下 base_url 和 model 名称就能切换到 DeepSeek。

提示：DeepSeek 的 API 接口和 OpenAI 的接口格式基本一致，迁移成本很低。但要注意模型名称的写法，不同版本的模型名称可能不一样。

2.4 Git：Agent 改代码时的安全网

Git 在 AI Agent 的工作流里扮演的是“安全网”的角色。每次让 Agent 修改代码之前，我都会先确保当前工作区是干净的，也就是所有改动都已经 commit 了。这样万一 Agent 改出了问题，我可以用git checkout .一键回滚。

我习惯的做法是：先创建一个新的分支，比如git checkout -b agent-experiment，然后让 Agent 在这个分支上操作。如果改得好，就 merge 回主分支；如果改得不好，直接删掉这个分支就行，主分支完全不受影响。这个习惯帮我避免了好几次因为 Agent 误删代码而导致的灾难。

2.5 工具选型对比

3. 环境搭建：从 Git 安装到 Codex 配置的完整流程

3.1 Git 安装与基础配置

Git 是整套工作流的基础，不管你用哪个 Agent，版本控制都是必须的。Windows 上安装 Git 比较简单，去官网下载安装包，一路下一步就行。安装完成后需要做几个基础配置，这些配置会影响你后续的 commit 记录和远程仓库操作。

git config --global user.name "你的名字" git config --global user.email "你的邮箱" git config --global init.defaultBranch main git config --global core.autocrlf input

这几条命令分别设置了用户名、邮箱、默认分支名和换行符处理方式。core.autocrlf input在 Windows 上特别有用，它能避免因为换行符差异导致的文件变更误报。我刚开始用 Git 的时候没设这个，结果每次 checkout 都提示文件被修改了，排查了半天才发现是换行符的问题。

配置 SSH 认证也是常见需求。如果你用 SSH 方式连接远程仓库，需要生成密钥对并把公钥添加到仓库平台。生成密钥的命令是ssh-keygen -t ed25519 -C "你的邮箱"，然后一路回车就行。生成完成后，公钥文件在~/.ssh/id_ed25519.pub，用文本编辑器打开复制内容，粘贴到仓库平台的 SSH 设置里。

注意：如果你遇到“ssh认证失败 git”的报错，先检查公钥是否正确添加，再用ssh -T git@github.com测试连接。如果还是失败，可能是网络问题或者密钥权限设置不对。

3.2 Codex 安装与登录

Codex 的安装方式有几种，我推荐用 npm 安装，因为更新比较方便。前提是你已经装了 Node.js，版本建议在 18 以上。

npm install -g @openai/codex

安装完成后，在终端输入codex就能启动。第一次启动会提示你登录，有两种方式：一是用 ChatGPT 账号，二是用 API Key。用 ChatGPT 账号登录的话，它会打开浏览器让你授权，授权完成后回到终端就能用了。

登录成功后，你会看到一个交互式界面，底部有输入框，你可以直接输入自然语言指令。比如输入“列出当前目录下所有 Python 文件”，它就会执行ls *.py或者类似的命令并把结果展示给你。

3.3 Codex 接入 DeepSeek 的配置方法

Codex 默认用的是 OpenAI 的模型，但你可以通过配置让它接入 DeepSeek。这个配置过程稍微有点绕，我当初也折腾了一阵子才搞明白。

首先你需要找到 Codex 的配置文件，通常在~/.codex/config.toml。如果文件不存在就手动创建一个。然后写入以下内容：

model = "deepseek-chat" model_provider = "deepseek" [model_providers.deepseek] name = "DeepSeek" base_url = "https://api.deepseek.com/v1" env_key = "DEEPSEEK_API_KEY"

这里的关键是model_provider字段，它告诉 Codex 用哪个提供商的模型。base_url指向 DeepSeek 的 API 地址，env_key指定了存放 API Key 的环境变量名。你需要在系统环境变量里设置DEEPSEEK_API_KEY，值就是你在 DeepSeek 平台申请的 API Key。

配置完成后重启 Codex，它就会用 DeepSeek 的模型来执行任务了。我实测下来，DeepSeek 在代码修改任务上的表现还不错，虽然偶尔会有理解偏差，但整体可用。

提示：如果你遇到“cc switch local proxy failed while handling codex endpoint /responses”这类报错，大概率是 base_url 配置不对或者 API Key 无效。先检查这两项，再看网络是否能正常访问 API 地址。

3.4 环境变量管理与安全

API Key 的管理是个容易被忽视但很重要的问题。我见过有人直接把 Key 写在代码里然后提交到公开仓库，结果被人盗刷。正确的做法是用环境变量或者专门的密钥管理工具。

在 Windows 上设置环境变量可以用系统设置界面，也可以用命令行：

setx DEEPSEEK_API_KEY "你的key"

在 macOS 或 Linux 上，可以写到~/.bashrc或~/.zshrc里：

export DEEPSEEK_API_KEY="你的key"

写完之后记得source ~/.bashrc让配置生效。另外，建议在.gitignore里加上.env和config.toml这类文件，避免不小心把密钥提交上去。

4. 实操流程：用 Agent 完成一个真实任务的完整记录

4.1 任务定义与前期准备

我拿一个真实的小任务来演示整个流程：有一个 Python 项目，里面有几个工具函数文件，我想让 Agent 帮我做三件事：一是把所有函数加上类型注解，二是把过时的os.path用法改成pathlib，三是确保修改后测试能跑通。

第一步是确保工作区干净。我先执行git status确认没有未提交的改动，然后创建一个新分支：

git checkout -b agent-refactor

这样做的好处是，如果 Agent 改砸了，我可以直接git checkout main切回主分支，然后删掉这个实验分支，主分支完全不受影响。

第二步是了解项目结构。我用tree -L 2看了一下目录布局，确认工具函数都在src/utils/下面。这一步很重要，因为你需要给 Agent 明确的文件范围，不然它可能会去改一些不该改的文件。

4.2 用 Codex 执行代码修改

启动 Codex 后，我输入了这样一段指令：

请对 src/utils/ 目录下的所有 Python 文件做以下修改： 1. 给所有函数加上类型注解 2. 把 os.path 相关的用法替换成 pathlib 3. 修改完成后运行 pytest 确认测试通过

Codex 收到指令后，先列出了它计划修改的文件，然后逐个读取、分析、修改。整个过程它会在终端里输出进度，你可以实时看到它在做什么。大概过了两三分钟，它完成了所有修改并运行了测试。

这里有个细节值得注意：Codex 在修改之前会先读取文件内容，理解现有代码的结构和风格，然后再做修改。它不会盲目地替换，而是会根据上下文判断。比如os.path.join会被替换成Path() /的写法，而不是简单地字符串替换。

修改完成后，我用git diff看了一下改动内容，确认没有问题后 commit 了：

git add -A git commit -m "refactor: add type hints and migrate to pathlib"

4.3 用 DeepSeek 做代码审查

Codex 改完之后，我又用 DeepSeek 做了一轮代码审查。我把修改后的文件内容发给 DeepSeek，让它检查有没有遗漏或者引入的新问题。DeepSeek 的推理能力在这个环节体现得比较明显，它指出了一处类型注解不够精确的地方，还建议了一个更简洁的 pathlib 写法。

这个“双工具交叉验证”的做法是我自己摸索出来的，效果不错。Codex 擅长执行具体的修改操作，DeepSeek 擅长分析和推理，两者配合使用能覆盖更多盲区。

4.4 参数选择与成本控制

在使用 API 类工具时，token 消耗是个绕不开的话题。token 简单理解就是文本的计量单位，一个中文字大概对应 1 到 2 个 token，英文单词也差不多。你发送的指令、Agent 读取的文件内容、它生成的回复，都会消耗 token。

控制成本有几个实用技巧：一是尽量缩小文件范围，不要让 Agent 去读整个项目；二是把长文件拆分成小段处理；三是用更便宜的模型做初步筛选，再用更强的模型做精细处理。我一般会先估算一下任务的 token 消耗，如果太大就拆成几个小任务分批做。

提示：DeepSeek 的 API 价格比 OpenAI 便宜不少，对于批量处理类的任务，用 DeepSeek 能省下可观的费用。但如果是需要高精度推理的任务，可能还是得用更强的模型。

5. 常见问题与排查技巧实录

5.1 安装与配置类问题

问题一：ChatGPT 无法加载 config.toml

这个报错通常是因为配置文件格式不对或者 model 字段的值不被支持。解决办法是打开 config.toml，检查 model 字段的值是否正确。如果你用的是 ChatGPT 账号登录，有些模型是不支持的，需要换成支持的模型名称。

问题二：Codex 登录失败

Codex 登录失败的原因可能有几种：网络问题、账号权限问题、或者本地缓存冲突。可以先尝试清除~/.codex目录下的缓存文件，然后重新登录。如果还是不行，换用 API Key 登录试试。

问题三：Git SSH 认证失败

先确认公钥是否正确添加到仓库平台，然后用ssh -T git@github.com测试连接。如果提示权限被拒绝，检查~/.ssh目录和密钥文件的权限，确保只有当前用户可读。

5.2 运行时报错类问题

问题四：cc switch local proxy failed

这个报错通常出现在 Codex 接入第三方 API 时，原因是 base_url 配置不对或者 API Key 无效。检查 config.toml 里的 base_url 是否指向正确的 API 地址，以及环境变量里的 API Key 是否有效。

问题五：模型不支持

“the ‘gpt-6.1-sol’ model is not supported when using codex with a chatgpt acc”这个报错的意思是，你用 ChatGPT 账号登录时不能用这个模型。解决办法是换一个支持的模型，或者改用 API Key 登录。

问题六：Agent 修改后测试不通过

这种情况先不要慌，用git diff看看 Agent 改了什么，找到问题所在。如果改动太多不好排查，直接git checkout .回滚，然后重新给 Agent 更明确的指令。我遇到过一次 Agent 把测试文件也改了导致测试通过的情况，后来我养成了习惯：每次 Agent 改完都先看 diff，确认它没有动不该动的文件。

5.3 常见问题速查表

5.4 独家避坑技巧

第一个技巧是“小步快跑”。不要一次性给 Agent 一个大任务，而是拆成多个小任务，每完成一个就检查一下。这样出问题时容易定位，回滚成本也低。

第二个技巧是“先读后写”。在让 Agent 修改代码之前，先让它读一遍相关文件并描述它理解的内容。如果它的理解有偏差，你能提前发现并纠正，避免它基于错误理解去改代码。

第三个技巧是“保留人工审核环节”。不管 Agent 表现多好，最终的代码审核还是得人来把关。我一般会用git diff仔细看一遍改动，确认没有问题再 commit。

第四个技巧是“记录每次操作的指令”。我会把每次给 Agent 的指令记在一个文本文件里，这样如果后面出了问题，可以回溯当时是怎么操作的。这个习惯帮我省了不少排查时间。

6. 进阶玩法：把 Agent 集成到日常开发流程

6.1 用脚本批量调用 API

当你熟悉了单个任务的操作后，可以考虑用脚本批量调用 API。比如我写了一个 Python 脚本，遍历指定目录下的所有文件，逐个发给 DeepSeek 做代码审查，然后把结果汇总到一个报告文件里。

import os import requests API_KEY = os.environ.get("DEEPSEEK_API_KEY") API_URL = "https://api.deepseek.com/v1/chat/completions" def review_file(filepath): with open(filepath, "r", encoding="utf-8") as f: content = f.read() response = requests.post( API_URL, headers={"Authorization": f"Bearer {API_KEY}"}, json={ "model": "deepseek-chat", "messages": [ {"role": "system", "content": "你是一个代码审查助手，请指出代码中的问题并给出改进建议。"}, {"role": "user", "content": content} ] } ) return response.json()["choices"][0]["message"]["content"] for root, dirs, files in os.walk("src"): for file in files: if file.endswith(".py"): filepath = os.path.join(root, file) print(f"审查文件：{filepath}") result = review_file(filepath) print(result) print("-" * 50)

这个脚本的核心逻辑就是遍历文件、调用 API、输出结果。你可以根据自己的需求调整提示词和文件过滤条件。

6.2 用 Git Hook 自动触发审查

更进一步的做法是用 Git Hook 在 commit 之前自动触发 Agent 审查。在.git/hooks/pre-commit里写一个脚本，每次 commit 时自动把改动的文件发给 Agent 检查，如果有问题就阻止 commit。

#!/bin/bash changed_files=$(git diff --cached --name-only --diff-filter=ACM | grep '\.py$') if [ -n "$changed_files" ]; then echo "正在审查改动的文件..." for file in $changed_files; do python review_script.py "$file" done fi

这个做法能帮你养成每次提交前都检查的习惯，减少低级错误进入仓库的概率。不过要注意，Hook 脚本执行时间不宜过长，否则会影响开发效率。

6.3 Agent 工作流的未来扩展方向

我现在还在探索几个方向：一是把 Agent 接入 CI/CD 流程，在代码合并前自动做一轮审查；二是用 Agent 自动生成测试用例，覆盖那些人工容易遗漏的边界情况；三是把多个 Agent 串联起来，一个负责改代码，一个负责审查，一个负责跑测试，形成一个自动化流水线。

这些想法还在实验阶段，有些已经跑通了，有些还在踩坑。但整体方向我觉得是对的：Agent 不是要替代人，而是把人从重复性劳动里解放出来，让人能专注于更有创造性的工作。

提示：在把 Agent 接入自动化流程之前，先在手动模式下跑通整个流程，确认每个环节都稳定可靠。自动化流程出问题时排查起来比手动操作麻烦得多。

6.4 关于 token 消耗的进一步说明

很多人关心 token 消耗的问题，我在这里再展开说一下。token 消耗主要取决于三个因素：输入长度、输出长度、模型单价。输入长度包括你的指令和 Agent 读取的文件内容，输出长度是 Agent 生成的回复。

降低 token 消耗的方法有几种：一是精简指令，把不必要的描述去掉；二是限制文件范围，只让 Agent 读取相关文件；三是用更便宜的模型做初步处理；四是把长文件拆分成小段。我一般会先估算一下任务的 token 消耗，如果太大就拆成几个小任务分批做。

另外，不同模型的 token 计价方式不一样，有的按输入输出分别计价，有的统一计价。在选择模型时，除了看能力，也要看价格，找到性价比最高的那个。

6.5 一些个人体会

用了这么久 AI Agent，我最大的体会是：它确实能提升效率，但前提是你得知道怎么用它。把它当成一个能力很强但需要指导的助手，给它明确的任务、清晰的边界、及时的反馈，它就能发挥出很大的价值。反过来，如果你指望它全自动地解决所有问题，那大概率会失望。

另外，工具在快速迭代，今天好用的方法明天可能就过时了。保持学习的心态，多尝试新工具和新玩法，但也不要盲目追新。找到适合自己工作流的组合，然后持续优化，这比什么都重要。

最后分享一个小技巧：我会定期回顾自己给 Agent 的指令记录，看看哪些指令效果好、哪些效果差，然后总结出一些常用的指令模板。这个习惯让我给 Agent 派活的效率越来越高，返工率也越来越低。