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 GitAgent 改代码时的安全网Git 在 AI Agent 的工作流里扮演的是“安全网”的角色。每次让 Agent 修改代码之前我都会先确保当前工作区是干净的也就是所有改动都已经 commit 了。这样万一 Agent 改出了问题我可以用git checkout .一键回滚。我习惯的做法是先创建一个新的分支比如git checkout -b agent-experiment然后让 Agent 在这个分支上操作。如果改得好就 merge 回主分支如果改得不好直接删掉这个分支就行主分支完全不受影响。这个习惯帮我避免了好几次因为 Agent 误删代码而导致的灾难。2.5 工具选型对比工具核心优势主要限制适合场景ChatGPT通用性强知识面广无法直接访问本地文件查资料、解释概念、写文档Codex命令行操作直接改代码模型支持有限需登录代码修改、重构、批量替换DeepSeek推理能力强价格友好本地部署有硬件门槛深度分析、批量处理、代码审查Git版本控制安全回滚需要手动管理分支所有 Agent 操作的安全保障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 gitgithub.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 pathlib4.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 gitgithub.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 常见问题速查表问题现象可能原因解决方法ChatGPT 无法加载 config.toml配置文件格式错误检查 model 字段值Codex 登录失败网络或缓存问题清除缓存后重试SSH 认证失败公钥未添加或权限不对重新添加公钥检查权限cc switch local proxy failedbase_url 或 API Key 错误检查配置和环境变量模型不支持账号类型与模型不匹配换模型或换登录方式Agent 改完测试不通过修改引入新问题看 diff必要时回滚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, encodingutf-8) as f: content f.read() response requests.post( API_URL, headers{Authorization: fBearer {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-filterACM | 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 派活的效率越来越高返工率也越来越低。