1. 从“Farming Code”说起为什么这个词突然火了第一次看到“Farming Code”这个说法是在几个做 AI 工具链的朋友群里。有人发了一张截图配文是“今天又在 farm code 了”底下跟了一串“1”。当时我以为是某种新的代码生成玩法后来聊下来才明白这个词描述的是一种工作状态把 AI 编码助手当成一块“地”你负责播种写提示、给上下文、配环境它负责长出代码你再去收割、修剪、补种。整个过程像种田所以叫 farming。这个说法背后其实藏着一个很现实的变化。过去我们写代码核心动作是“敲”现在用 Codex、Claude Code 这类工具核心动作变成了“配置 引导 验收”。你的产出效率很大程度上不取决于你打字多快而取决于你把这块“地”养得多好——环境配得对不对、上下文给得准不准、工具链接得顺不顺。这也是为什么最近关于 agent、codex、claude、Language Server 的讨论会这么密集大家其实都在摸索同一件事怎么把 AI 编码这件事从“偶尔用一下”变成“稳定产出的日常”。这篇内容我想聊的就是这套“farming”的完整打法。从环境搭建、工具选型到 agent 架构的理解、Language Server 的作用再到实际跑起来之后各种报错怎么排查。适合两类人看一类是刚接触 Codex、Claude Code想把它真正用起来的开发者另一类是已经在用但总觉得“时灵时不灵”想搞清楚底层逻辑、把稳定性提上去的人。我不会只讲概念会把参数、配置、踩过的坑都摊开说尽量让你看完能直接抄作业。2. 先搞清楚几个概念agent、Codex、Claude Code 到底啥关系2.1 agent 不是工具是一种工作模式很多人一上来就把 agent 当成某个软件的名字这其实是个误解。agent 更像是一种“工作模式”的统称你给它一个目标它自己拆解步骤、调用工具、观察结果、再决定下一步。它和传统的“你问一句它答一句”最大的区别在于自主循环。打个比方普通对话式 AI 像是一个坐在你旁边的顾问你问什么它答什么它不会主动去翻你的文件。而 agent 更像是一个实习生你说“把这个模块的测试补上”它会自己去读代码、找测试框架、写用例、跑一遍、发现失败、再改。这个“自己跑一遍再改”的循环就是 agent 的核心。热词里有个“harness 和 agent 区别”这个问题问得很到位。harness测试夹具/执行框架负责的是“怎么把一次执行跑起来、怎么收集结果”它是被动的、确定性的agent 负责的是“决定下一步做什么”它是主动的、带决策的。两者经常一起出现但职责完全不同。你搭 agent 的时候harness 是它的手脚决策逻辑才是它的大脑。2.2 Codex 和 Claude Code 是两套不同的“农具”Codex 和 Claude Code 都属于“把大模型能力接进编码工作流”的工具但它们的定位和接入方式有差别。Codex 更偏向于一个可编程的编码能力接口你可以通过 API、CLI 或者 IDE 插件去调用它它的强项在于和现有工程体系的集成比如接进 CI、接进编辑器、接进自定义脚本。Claude Code 则更强调“在终端里和你一起干活”的体验它直接读你的项目目录、执行命令、改文件交互感更强。选哪个不是非此即彼。我自己的做法是需要批量、自动化、接进流水线的任务走 Codex 那条线需要边聊边改、探索性强的任务用 Claude Code。两者共享同一套“上下文管理”的思路所以你在一个上面练出来的提示技巧换到另一个基本也能用。2.3 Language Server 为什么会被反复提到Language Server 原本是编辑器领域的东西它的作用是给编辑器提供代码补全、跳转、诊断这些能力。它和 AI 编码工具的结合点在于AI 需要准确理解你的代码结构而 Language Server 正好能提供这份结构化的信息。举个实际场景。你让 AI 改一个函数如果它只看到你贴的那一段文本它可能不知道这个函数被哪些地方调用、参数类型是什么。但如果它接上了 Language Server就能拿到符号定义、引用关系、类型信息改起来就准得多。这也是为什么很多人在配置 Codex 或 Claude Code 时会去折腾 Language Server——不是为了好看是为了让 AI 少犯“改错地方”的毛病。3. 环境搭建从零把这块“地”开出来3.1 安装前的准备先确认你的系统底子安装这一步坑最多。热词里“codex安装 windows桌面版”“claude code 安装”“ubuntu配置claude code”这些搜索量高说明大家都在这一步卡过。我先把通用前提说清楚。不管装哪个你都需要一个能跑 Node.js 的环境因为大部分这类工具的 CLI 和插件都是基于 Node 生态的。建议 Node 版本不低于 18最好用 20 或 22 的 LTS。检查命令很简单node -v npm -v如果版本太低别硬上先升级。我见过太多“装完了跑不起来”的案例最后发现是 Node 版本太老。Windows 用户要特别注意一点热词里提到“claudes workspace requires the virtual machine platform on windows. enable”这个提示的意思是某个功能依赖 Windows 的虚拟机平台组件。遇到这个提示去“启用或关闭 Windows 功能”里把“虚拟机平台”勾上重启即可。这不是 bug是功能依赖。3.2 Codex 的安装与登录流程Codex 的安装官方渠道是首选。热词里“codex官网下载”“codex安装包”“codex下载”都在找安装包我的建议是永远从官方渠道拿第三方打包的版本你没法确认里面改了什么。安装完之后第一步是登录。热词里“codex登录”“codex登录不上”是高频问题。登录不上的常见原因有三个网络环境不稳定、账号权限没配好、本地缓存了旧的凭证。排查顺序建议是先确认账号本身能正常登录官方平台再清掉本地缓存重新登录最后才怀疑网络。登录成功后建议先跑一个最小验证比如让它生成一个简单的函数确认整条链路是通的再去接复杂项目。这一步很多人跳过结果后面出问题时分不清是环境问题还是使用问题。3.3 Claude Code 的安装与 VS Code 集成Claude Code 的安装相对直接但和 VS Code 的集成是重点。热词里“claude code for vs code”“vscode配置claude code”说明很多人是冲着编辑器集成去的。集成的时候有个关键点工作目录的选择。Claude Code 会读取你当前工作目录下的文件作为上下文如果你在错误的目录启动它读到的就是一堆无关文件回答质量会断崖式下跌。我的习惯是每个项目单独开一个终端cd 到项目根目录再启动。另外热词里“claude code在线升级最新版本”也值得说一句。这类工具迭代很快新版本经常修掉一些让人抓狂的小问题。建议养成定期升级的习惯升级命令通常就是包管理器的那一套npm update -g anthropic-ai/claude-code升级完记得重启编辑器和终端不然可能还在用旧进程。3.4 一个容易被忽略的环节代理与端点配置热词里有一条很具体的报错“cc switch local proxy failed while handling codex endpoint /responses”。这个报错的意思是本地代理在处理某个请求端点时失败了。这类问题的根源通常是端点地址配错了或者本地代理和工具期望的协议对不上。处理这类问题的思路是先确认你配置的端点地址是不是工具当前版本支持的格式再确认本地代理有没有正确转发。很多时候不是代理本身坏了而是配置里多了一个斜杠、少了一个路径段。我建议把配置项单独拎出来一项一项对照官方文档核对别凭记忆填。4. 核心机制拆解让 AI 稳定产出代码的关键4.1 上下文管理farming 的“土壤肥力”如果说环境是地那上下文就是肥力。AI 编码工具产出质量的高低八成取决于你给它的上下文质量。上下文分三层。第一层是项目级上下文也就是它能看到哪些文件。第二层是任务级上下文也就是你这次让它干什么、相关的代码片段有哪些。第三层是约束级上下文比如代码规范、命名习惯、禁止使用的库。很多人只给了第二层然后抱怨 AI 不懂自己的项目。正确的做法是让工具能访问到项目结构同时用配置文件把约束固化下来。比如在项目根目录放一个说明文件写清楚技术栈、目录约定、代码风格工具每次启动都会读相当于给这块地施了底肥。4.2 agent 的记忆机制为什么它有时候“忘了”热词里“agent记忆”是个高频词。agent 的记忆大致分两类会话内记忆和跨会话记忆。会话内记忆就是当前这轮对话的上下文窗口窗口满了早期内容就会被挤掉表现出来就是“它忘了前面说过的”。跨会话记忆则是通过外部存储实现的比如把关键决策写进文件下次启动时读回来。理解这一点很重要因为它决定了你的工作方式。对于长任务不要指望它一口气记住所有东西要主动把关键信息落到文件里。我自己的习惯是每完成一个阶段就让 agent 把当前状态和待办写进一个进度文件下次接着干的时候先让它读这个文件。这样即使换了会话也不会断片。4.3 agent 架构从单轮到多轮的跃迁一个能用的 agent 架构通常包含四个部分规划器、执行器、工具层、记忆层。规划器负责拆任务执行器负责调模型工具层负责读写文件、跑命令记忆层负责存状态。热词里“agent架构”“agent框架”“基于rust语言ai agent”这些说明大家已经在往更工程化的方向走了。用 Rust 写 agent 的好处是性能和资源占用可控适合长时间运行用脚本语言写的好处是迭代快。选哪个取决于你的场景如果是本地跑着玩脚本语言够了如果要常驻、要处理大量并发Rust 这类系统级语言更合适。4.4 agent 安全别把钥匙交给陌生人热词里“agent安全”必须单独拎出来说。agent 能读文件、能执行命令这意味着它的权限边界就是你的安全边界。几条硬规矩第一不要让 agent 在敏感目录下无限制运行给它划定工作区。第二执行删除、覆盖类命令前要有人工确认别开全自动。第三不要把密钥、凭证放在 agent 能读到的明文文件里用环境变量或者专门的密钥管理。第四审查它生成的命令尤其是涉及网络和文件系统的。我见过有人图省事让 agent 在 home 目录下随便跑结果它把一个配置文件覆盖了。这种坑踩一次就够记一辈子。5. 实操全流程一次完整的 farming 记录5.1 任务定义把模糊需求变成可执行指令假设我要给一个现有项目加一个功能给用户列表接口加上分页。这个需求听起来简单但如果直接丢给 AI它可能给你一堆不匹配的代码。正确的做法是先把它拆成可执行的指令。我会这样组织先说明项目技术栈和目录结构再指出要改的文件然后给出具体的分页参数约定比如 page 从 1 开始、size 默认 20、返回结构包含 total最后说明不能破坏现有测试。这一套下来AI 的产出质量会明显不一样。这里的关键是约束前置。你越早把边界说清楚后面返工越少。5.2 执行与观察像看庄稼一样看它干活启动之后不要撒手不管。我的习惯是盯着它的每一步操作尤其是它要改文件、跑命令的时候。看到它读了一个不该读的文件或者要执行一个危险命令立刻打断。观察的重点有三个它有没有理解对任务、它调用的工具是不是合理、它的中间结果有没有偏离预期。一旦发现偏了越早纠正成本越低。等它写完一大堆代码再回头改那基本等于重来。5.3 验收与修剪产出不等于可用AI 写完代码只是第一步。接下来要做的验收包括跑测试、看 diff、检查边界情况。我一般会重点看几类问题空值处理、并发情况、错误分支、日志输出。这些地方 AI 最容易偷懒。发现问题的处理方式也有讲究。不要直接说“你错了重写”而是指出具体哪里不对、期望是什么。比如“这个分页在 page 超出范围时应该返回空列表而不是报错”这样它改起来才准。5.4 参数与配置的实操示例下面给一个我常用的配置片段用于约束 agent 的行为。这不是某个工具的官方配置而是我根据常见实践整理的一个模板你可以按自己工具的实际字段去映射{ workspace: ./src, readonly: [./config/secrets, ./.env], confirmBefore: [delete, overwrite, network], contextFiles: [README.md, ARCHITECTURE.md, CODESTYLE.md], maxIterations: 20 }几个参数解释一下。workspace限定工作区防止它乱跑。readonly把敏感目录设成只读。confirmBefore列出需要人工确认的操作类型。contextFiles是每次启动都加载的上下文文件。maxIterations防止它陷入死循环跑太多轮还没结果就该人工介入了。这些值的设定逻辑是能限制就限制能确认就确认。宁可多按几次确认也不要让它自作主张。6. 常见问题与排查速查6.1 安装与登录类问题现象可能原因处理方式安装后命令找不到全局路径没配好检查 PATH重装并确认全局安装登录一直转圈网络或凭证问题清缓存重登确认账号状态Windows 提示需要虚拟机平台功能依赖未启用启用“虚拟机平台”并重启升级后行为异常旧进程未退出重启终端和编辑器6.2 运行时报错类问题热词里“codex无法加载组织设置”“the gpt-5.6-sol model is not supported”这类报错本质上是配置和当前版本不匹配。模型名不被支持说明你配置里写的模型标识在当前工具版本里已经变了或者不存在。处理方式是去官方文档核对当前支持的模型列表别用记忆里的旧名字。“无法加载组织设置”通常是权限或者配置同步的问题。先确认账号有没有对应组织的访问权限再检查本地配置有没有残留旧的组织信息。6.3 代理与端点类问题前面提到的“local proxy failed”那类报错排查顺序建议是先看端点地址格式对不对再看本地代理日志有没有转发记录最后确认工具版本和代理版本是否兼容。很多时候升级一下工具就好了因为端点协议可能变了。6.4 独家避坑技巧第一条每次大改动前先提交一次。AI 改代码是不可预测的有 git 兜底你随时能回滚。第二条把成功的提示词存下来。你会发现某些提示结构特别有效存成模板下次直接改参数用。第三条别在同一个会话里塞太多不相关的任务上下文会互相污染一个任务一个会话最干净。第四条遇到反复出错的问题先怀疑环境而不是模型八成是配置问题。7. 工具选型与扩展把 farming 做成体系7.1 Codex 接入其他模型的思路热词里“codex接入deepseek”说明大家不满足于只用一家模型。接入第三方模型的思路是找到工具的模型配置入口把端点地址和模型标识换成目标服务的。这里要注意的是协议兼容性不是所有模型服务都完全兼容同一套接口格式可能需要中间做一层适配。适配层的做法通常是写一个轻量转发服务把工具的请求格式转成目标服务的格式再把响应转回来。这层服务不用复杂核心就是字段映射和错误处理。7.2 多工具协同的工作流我现在的日常是 Codex 和 Claude Code 混用。探索性任务用 Claude Code因为交互顺批量任务用 Codex因为好集成。两者共享同一套项目上下文文件所以切换成本很低。如果你还想更进一步可以把 agent 接进 CI让它在提交时自动跑检查、生成测试、甚至修简单的问题。但这一步要谨慎自动化程度越高出错的破坏力越大一定要有完善的回滚和审查机制。7.3 从“用工具”到“养工具”farming 这个词的精髓在于“养”。工具不是装完就完事你需要持续地喂它上下文、调它的配置、记录它的表现。我建议建一个自己的“农事日志”记录每次任务的提示、产出质量、遇到的问题。积累一段时间后你会发现自己对什么任务该用什么提示、什么配置最稳有了直觉。这份直觉才是别人抄不走的竞争力。8. 我踩过的几个真实坑说几个具体的。有一次我在一个 monorepo 里启动工具没注意工作目录结果它把整个仓库当上下文读了一遍回答里混进了完全不相关模块的代码。后来我养成习惯启动前先pwd确认位置。还有一次我让 agent 帮我重构一个函数它改完之后测试全绿我就直接提交了。结果上线后发现一个边界情况没覆盖因为原来的测试本身就没测那个分支。这件事让我明白AI 的产出质量上限受限于你的测试质量。测试写得糙AI 改得再顺也白搭。最后一个关于模型名。我有次照着一篇旧教程配了模型标识结果一直报不支持。折腾了半天才发现教程是半年前的模型早就换名字了。从那以后配置类的东西我一律以官方文档为准教程只用来理解思路。这套 farming 的打法说到底就是把 AI 编码从“碰运气”变成“可复现”。环境配稳、上下文喂足、边界划清、验收做严产出自然就稳了。工具会一直变但这套思路不太会过时。 
长河君 · 2026/10/8 4:20:12 · 阅读 1.2k AI编码助手Farming实战：Codex与Claude Code环境搭建、Agent架构与避坑指南
1. 从“Farming Code”说起为什么这个词突然火了第一次看到“Farming Code”这个说法是在几个做 AI 工具链的朋友群里。有人发了一张截图配文是“今天又在 farm code 了”底下跟了一串“1”。当时我以为是某种新的代码生成玩法后来聊下来才明白这个词描述的是一种工作状态把 AI 编码助手当成一块“地”你负责播种写提示、给上下文、配环境它负责长出代码你再去收割、修剪、补种。整个过程像种田所以叫 farming。这个说法背后其实藏着一个很现实的变化。过去我们写代码核心动作是“敲”现在用 Codex、Claude Code 这类工具核心动作变成了“配置 引导 验收”。你的产出效率很大程度上不取决于你打字多快而取决于你把这块“地”养得多好——环境配得对不对、上下文给得准不准、工具链接得顺不顺。这也是为什么最近关于 agent、codex、claude、Language Server 的讨论会这么密集大家其实都在摸索同一件事怎么把 AI 编码这件事从“偶尔用一下”变成“稳定产出的日常”。这篇内容我想聊的就是这套“farming”的完整打法。从环境搭建、工具选型到 agent 架构的理解、Language Server 的作用再到实际跑起来之后各种报错怎么排查。适合两类人看一类是刚接触 Codex、Claude Code想把它真正用起来的开发者另一类是已经在用但总觉得“时灵时不灵”想搞清楚底层逻辑、把稳定性提上去的人。我不会只讲概念会把参数、配置、踩过的坑都摊开说尽量让你看完能直接抄作业。2. 先搞清楚几个概念agent、Codex、Claude Code 到底啥关系2.1 agent 不是工具是一种工作模式很多人一上来就把 agent 当成某个软件的名字这其实是个误解。agent 更像是一种“工作模式”的统称你给它一个目标它自己拆解步骤、调用工具、观察结果、再决定下一步。它和传统的“你问一句它答一句”最大的区别在于自主循环。打个比方普通对话式 AI 像是一个坐在你旁边的顾问你问什么它答什么它不会主动去翻你的文件。而 agent 更像是一个实习生你说“把这个模块的测试补上”它会自己去读代码、找测试框架、写用例、跑一遍、发现失败、再改。这个“自己跑一遍再改”的循环就是 agent 的核心。热词里有个“harness 和 agent 区别”这个问题问得很到位。harness测试夹具/执行框架负责的是“怎么把一次执行跑起来、怎么收集结果”它是被动的、确定性的agent 负责的是“决定下一步做什么”它是主动的、带决策的。两者经常一起出现但职责完全不同。你搭 agent 的时候harness 是它的手脚决策逻辑才是它的大脑。2.2 Codex 和 Claude Code 是两套不同的“农具”Codex 和 Claude Code 都属于“把大模型能力接进编码工作流”的工具但它们的定位和接入方式有差别。Codex 更偏向于一个可编程的编码能力接口你可以通过 API、CLI 或者 IDE 插件去调用它它的强项在于和现有工程体系的集成比如接进 CI、接进编辑器、接进自定义脚本。Claude Code 则更强调“在终端里和你一起干活”的体验它直接读你的项目目录、执行命令、改文件交互感更强。选哪个不是非此即彼。我自己的做法是需要批量、自动化、接进流水线的任务走 Codex 那条线需要边聊边改、探索性强的任务用 Claude Code。两者共享同一套“上下文管理”的思路所以你在一个上面练出来的提示技巧换到另一个基本也能用。2.3 Language Server 为什么会被反复提到Language Server 原本是编辑器领域的东西它的作用是给编辑器提供代码补全、跳转、诊断这些能力。它和 AI 编码工具的结合点在于AI 需要准确理解你的代码结构而 Language Server 正好能提供这份结构化的信息。举个实际场景。你让 AI 改一个函数如果它只看到你贴的那一段文本它可能不知道这个函数被哪些地方调用、参数类型是什么。但如果它接上了 Language Server就能拿到符号定义、引用关系、类型信息改起来就准得多。这也是为什么很多人在配置 Codex 或 Claude Code 时会去折腾 Language Server——不是为了好看是为了让 AI 少犯“改错地方”的毛病。3. 环境搭建从零把这块“地”开出来3.1 安装前的准备先确认你的系统底子安装这一步坑最多。热词里“codex安装 windows桌面版”“claude code 安装”“ubuntu配置claude code”这些搜索量高说明大家都在这一步卡过。我先把通用前提说清楚。不管装哪个你都需要一个能跑 Node.js 的环境因为大部分这类工具的 CLI 和插件都是基于 Node 生态的。建议 Node 版本不低于 18最好用 20 或 22 的 LTS。检查命令很简单node -v npm -v如果版本太低别硬上先升级。我见过太多“装完了跑不起来”的案例最后发现是 Node 版本太老。Windows 用户要特别注意一点热词里提到“claudes workspace requires the virtual machine platform on windows. enable”这个提示的意思是某个功能依赖 Windows 的虚拟机平台组件。遇到这个提示去“启用或关闭 Windows 功能”里把“虚拟机平台”勾上重启即可。这不是 bug是功能依赖。3.2 Codex 的安装与登录流程Codex 的安装官方渠道是首选。热词里“codex官网下载”“codex安装包”“codex下载”都在找安装包我的建议是永远从官方渠道拿第三方打包的版本你没法确认里面改了什么。安装完之后第一步是登录。热词里“codex登录”“codex登录不上”是高频问题。登录不上的常见原因有三个网络环境不稳定、账号权限没配好、本地缓存了旧的凭证。排查顺序建议是先确认账号本身能正常登录官方平台再清掉本地缓存重新登录最后才怀疑网络。登录成功后建议先跑一个最小验证比如让它生成一个简单的函数确认整条链路是通的再去接复杂项目。这一步很多人跳过结果后面出问题时分不清是环境问题还是使用问题。3.3 Claude Code 的安装与 VS Code 集成Claude Code 的安装相对直接但和 VS Code 的集成是重点。热词里“claude code for vs code”“vscode配置claude code”说明很多人是冲着编辑器集成去的。集成的时候有个关键点工作目录的选择。Claude Code 会读取你当前工作目录下的文件作为上下文如果你在错误的目录启动它读到的就是一堆无关文件回答质量会断崖式下跌。我的习惯是每个项目单独开一个终端cd 到项目根目录再启动。另外热词里“claude code在线升级最新版本”也值得说一句。这类工具迭代很快新版本经常修掉一些让人抓狂的小问题。建议养成定期升级的习惯升级命令通常就是包管理器的那一套npm update -g anthropic-ai/claude-code升级完记得重启编辑器和终端不然可能还在用旧进程。3.4 一个容易被忽略的环节代理与端点配置热词里有一条很具体的报错“cc switch local proxy failed while handling codex endpoint /responses”。这个报错的意思是本地代理在处理某个请求端点时失败了。这类问题的根源通常是端点地址配错了或者本地代理和工具期望的协议对不上。处理这类问题的思路是先确认你配置的端点地址是不是工具当前版本支持的格式再确认本地代理有没有正确转发。很多时候不是代理本身坏了而是配置里多了一个斜杠、少了一个路径段。我建议把配置项单独拎出来一项一项对照官方文档核对别凭记忆填。4. 核心机制拆解让 AI 稳定产出代码的关键4.1 上下文管理farming 的“土壤肥力”如果说环境是地那上下文就是肥力。AI 编码工具产出质量的高低八成取决于你给它的上下文质量。上下文分三层。第一层是项目级上下文也就是它能看到哪些文件。第二层是任务级上下文也就是你这次让它干什么、相关的代码片段有哪些。第三层是约束级上下文比如代码规范、命名习惯、禁止使用的库。很多人只给了第二层然后抱怨 AI 不懂自己的项目。正确的做法是让工具能访问到项目结构同时用配置文件把约束固化下来。比如在项目根目录放一个说明文件写清楚技术栈、目录约定、代码风格工具每次启动都会读相当于给这块地施了底肥。4.2 agent 的记忆机制为什么它有时候“忘了”热词里“agent记忆”是个高频词。agent 的记忆大致分两类会话内记忆和跨会话记忆。会话内记忆就是当前这轮对话的上下文窗口窗口满了早期内容就会被挤掉表现出来就是“它忘了前面说过的”。跨会话记忆则是通过外部存储实现的比如把关键决策写进文件下次启动时读回来。理解这一点很重要因为它决定了你的工作方式。对于长任务不要指望它一口气记住所有东西要主动把关键信息落到文件里。我自己的习惯是每完成一个阶段就让 agent 把当前状态和待办写进一个进度文件下次接着干的时候先让它读这个文件。这样即使换了会话也不会断片。4.3 agent 架构从单轮到多轮的跃迁一个能用的 agent 架构通常包含四个部分规划器、执行器、工具层、记忆层。规划器负责拆任务执行器负责调模型工具层负责读写文件、跑命令记忆层负责存状态。热词里“agent架构”“agent框架”“基于rust语言ai agent”这些说明大家已经在往更工程化的方向走了。用 Rust 写 agent 的好处是性能和资源占用可控适合长时间运行用脚本语言写的好处是迭代快。选哪个取决于你的场景如果是本地跑着玩脚本语言够了如果要常驻、要处理大量并发Rust 这类系统级语言更合适。4.4 agent 安全别把钥匙交给陌生人热词里“agent安全”必须单独拎出来说。agent 能读文件、能执行命令这意味着它的权限边界就是你的安全边界。几条硬规矩第一不要让 agent 在敏感目录下无限制运行给它划定工作区。第二执行删除、覆盖类命令前要有人工确认别开全自动。第三不要把密钥、凭证放在 agent 能读到的明文文件里用环境变量或者专门的密钥管理。第四审查它生成的命令尤其是涉及网络和文件系统的。我见过有人图省事让 agent 在 home 目录下随便跑结果它把一个配置文件覆盖了。这种坑踩一次就够记一辈子。5. 实操全流程一次完整的 farming 记录5.1 任务定义把模糊需求变成可执行指令假设我要给一个现有项目加一个功能给用户列表接口加上分页。这个需求听起来简单但如果直接丢给 AI它可能给你一堆不匹配的代码。正确的做法是先把它拆成可执行的指令。我会这样组织先说明项目技术栈和目录结构再指出要改的文件然后给出具体的分页参数约定比如 page 从 1 开始、size 默认 20、返回结构包含 total最后说明不能破坏现有测试。这一套下来AI 的产出质量会明显不一样。这里的关键是约束前置。你越早把边界说清楚后面返工越少。5.2 执行与观察像看庄稼一样看它干活启动之后不要撒手不管。我的习惯是盯着它的每一步操作尤其是它要改文件、跑命令的时候。看到它读了一个不该读的文件或者要执行一个危险命令立刻打断。观察的重点有三个它有没有理解对任务、它调用的工具是不是合理、它的中间结果有没有偏离预期。一旦发现偏了越早纠正成本越低。等它写完一大堆代码再回头改那基本等于重来。5.3 验收与修剪产出不等于可用AI 写完代码只是第一步。接下来要做的验收包括跑测试、看 diff、检查边界情况。我一般会重点看几类问题空值处理、并发情况、错误分支、日志输出。这些地方 AI 最容易偷懒。发现问题的处理方式也有讲究。不要直接说“你错了重写”而是指出具体哪里不对、期望是什么。比如“这个分页在 page 超出范围时应该返回空列表而不是报错”这样它改起来才准。5.4 参数与配置的实操示例下面给一个我常用的配置片段用于约束 agent 的行为。这不是某个工具的官方配置而是我根据常见实践整理的一个模板你可以按自己工具的实际字段去映射{ workspace: ./src, readonly: [./config/secrets, ./.env], confirmBefore: [delete, overwrite, network], contextFiles: [README.md, ARCHITECTURE.md, CODESTYLE.md], maxIterations: 20 }几个参数解释一下。workspace限定工作区防止它乱跑。readonly把敏感目录设成只读。confirmBefore列出需要人工确认的操作类型。contextFiles是每次启动都加载的上下文文件。maxIterations防止它陷入死循环跑太多轮还没结果就该人工介入了。这些值的设定逻辑是能限制就限制能确认就确认。宁可多按几次确认也不要让它自作主张。6. 常见问题与排查速查6.1 安装与登录类问题现象可能原因处理方式安装后命令找不到全局路径没配好检查 PATH重装并确认全局安装登录一直转圈网络或凭证问题清缓存重登确认账号状态Windows 提示需要虚拟机平台功能依赖未启用启用“虚拟机平台”并重启升级后行为异常旧进程未退出重启终端和编辑器6.2 运行时报错类问题热词里“codex无法加载组织设置”“the gpt-5.6-sol model is not supported”这类报错本质上是配置和当前版本不匹配。模型名不被支持说明你配置里写的模型标识在当前工具版本里已经变了或者不存在。处理方式是去官方文档核对当前支持的模型列表别用记忆里的旧名字。“无法加载组织设置”通常是权限或者配置同步的问题。先确认账号有没有对应组织的访问权限再检查本地配置有没有残留旧的组织信息。6.3 代理与端点类问题前面提到的“local proxy failed”那类报错排查顺序建议是先看端点地址格式对不对再看本地代理日志有没有转发记录最后确认工具版本和代理版本是否兼容。很多时候升级一下工具就好了因为端点协议可能变了。6.4 独家避坑技巧第一条每次大改动前先提交一次。AI 改代码是不可预测的有 git 兜底你随时能回滚。第二条把成功的提示词存下来。你会发现某些提示结构特别有效存成模板下次直接改参数用。第三条别在同一个会话里塞太多不相关的任务上下文会互相污染一个任务一个会话最干净。第四条遇到反复出错的问题先怀疑环境而不是模型八成是配置问题。7. 工具选型与扩展把 farming 做成体系7.1 Codex 接入其他模型的思路热词里“codex接入deepseek”说明大家不满足于只用一家模型。接入第三方模型的思路是找到工具的模型配置入口把端点地址和模型标识换成目标服务的。这里要注意的是协议兼容性不是所有模型服务都完全兼容同一套接口格式可能需要中间做一层适配。适配层的做法通常是写一个轻量转发服务把工具的请求格式转成目标服务的格式再把响应转回来。这层服务不用复杂核心就是字段映射和错误处理。7.2 多工具协同的工作流我现在的日常是 Codex 和 Claude Code 混用。探索性任务用 Claude Code因为交互顺批量任务用 Codex因为好集成。两者共享同一套项目上下文文件所以切换成本很低。如果你还想更进一步可以把 agent 接进 CI让它在提交时自动跑检查、生成测试、甚至修简单的问题。但这一步要谨慎自动化程度越高出错的破坏力越大一定要有完善的回滚和审查机制。7.3 从“用工具”到“养工具”farming 这个词的精髓在于“养”。工具不是装完就完事你需要持续地喂它上下文、调它的配置、记录它的表现。我建议建一个自己的“农事日志”记录每次任务的提示、产出质量、遇到的问题。积累一段时间后你会发现自己对什么任务该用什么提示、什么配置最稳有了直觉。这份直觉才是别人抄不走的竞争力。8. 我踩过的几个真实坑说几个具体的。有一次我在一个 monorepo 里启动工具没注意工作目录结果它把整个仓库当上下文读了一遍回答里混进了完全不相关模块的代码。后来我养成习惯启动前先pwd确认位置。还有一次我让 agent 帮我重构一个函数它改完之后测试全绿我就直接提交了。结果上线后发现一个边界情况没覆盖因为原来的测试本身就没测那个分支。这件事让我明白AI 的产出质量上限受限于你的测试质量。测试写得糙AI 改得再顺也白搭。最后一个关于模型名。我有次照着一篇旧教程配了模型标识结果一直报不支持。折腾了半天才发现教程是半年前的模型早就换名字了。从那以后配置类的东西我一律以官方文档为准教程只用来理解思路。这套 farming 的打法说到底就是把 AI 编码从“碰运气”变成“可复现”。环境配稳、上下文喂足、边界划清、验收做严产出自然就稳了。工具会一直变但这套思路不太会过时。