把编码 Agent 装回本机：三个取舍和一份边界清单

本地跑编码 Agent 这件事，试过的人大概都经历过三个阶段：先兴奋，再失望，最后找到一个稳定的用法。中间那次失望，大多来自预期错位。

这篇写我怎么用它，以及绕不过去的三个取舍。

取舍一：能力上限和可控性

云端模型更强，但代码要出本机；本地模型可控，但复杂重构经常做不利索。

我的做法是按任务分：涉及大量文件、需要跨模块推理的活交给强模型；涉及内部规范、不方便外传的部分用本地模型跑。

这不是立场问题，是成本收益问题。硬要一站到底，通常两头都不满意。

取舍二：上下文怎么给

命令行 Agent 最大的价值是能直接读仓库。但把整个仓库塞进去既不现实也不划算。

有效的做法是给它明确的入口：目录结构、几个关键文件，再加一份说明当前任务的短文档。让它顺着线索自己去找，比一次吞下所有东西更稳。

我习惯在仓库根放一个约定文件，写清技术栈、构建与测试命令、代码风格、以及不许碰的目录。这个几十行的小文件对效果的影响，往往比换模型还大。

取舍三：权限边界

Agent 能执行命令，就意味着它能改文件、装依赖、发网络请求。

一开始就该划死边界：只允许在工作目录内读写，破坏性命令必须人工确认，网络访问按需开。

这不是不信任模型，是承认它会犯错。等出了事再补限制，代价是数据和返工时间。

环境准备比选模型更花时间

真正耗时的不是装工具，而是把环境跑通：依赖版本、构建命令、测试能不能在无网络下跑、日志输出到哪。

如果项目本身没有可重复的构建流程，Agent 会把这些坑一个个踩给你看。所以先用 CI 把流程固定下来，再接 Agent，会顺很多。

三种常见误用

• 让它一次改十几个文件：改动越大越难审，出错也越难定位
• 不给验收标准：它只能猜你要什么，猜错就是白干
• 完全放手：尤其在测试和配置上，它的判断经常过于乐观

改法都很朴素：一次一件事、先说清验收条件、改完必须人工过一遍。

我实际让它做什么

• 补测试：给一个函数和现有测试风格，让它补齐边界用例，人来筛
• 改样板代码：批量重命名、接口适配、日志补全
• 读陌生仓库：先让它输出调用关系，再人工确认关键路径

架构决策、安全相关改动、涉及线上配置的操作，我一律不交给它。

什么时候该换成云端

判断标准是任务的「推理深度」，而不是改动代码的行数。改一个字段名和改一个函数签名，看起来都很短，但后者要理解调用链。

我的经验阈值是：如果一件事需要同时看三个以上文件才能决定怎么做，就交给更强的模型；如果是机械替换，本地跑更省事也更安全。

另外，本地模型对项目里的私有术语几乎没有概念，靠约定文件补，往往补不齐。这类活留在云端更划算。

结论

本地 Agent 现在的位置，更像一个手很快、但需要带教的实习生。把活拆细、把边界定清楚，它能省下大量机械时间；指望它独立交付一个模块，多半要返工。

先明确哪些事不做，剩下的效率提升才稳。

本文不构成任何技术建议，具体工具与方案请结合自身环境评估。