Coding Agent进化论：从代码助手到交付结果的许愿机

这几年的技术圈里，Coding Agent 大概是出现频率最高的词之一，但站在一线把这类系统做深之后，我越来越觉得这个名字已经罩不住实际在做的事了。你给它一句“帮我把这个仓库的新依赖推上去”，它不只是改写代码，而是会读文档、跑测试、回滚、给你留一份变更说明——它接收的是愿望，交付的是结果。这哪里还是“写代码的工具”，分明是台粗糙但能跑的许愿机。这篇文章我会从形态演变、技术内幕、工程化落地、真实场景和踩坑实录几个角度，把这台“许愿机”从头到脚拆一遍。不管你是开发者、技术负责人，还是想用 AI 做内部工具的产品经理，都应该能从里面找到可以直接抄作业的部分。

1. Coding Agent 为什么正在变成许愿机：形态进化与边界重置

1.1 早期的 Coding 工具：输入代码，输出代码

严格说，人类用自动工具写代码的历史，比大模型早得多。早期的代码补全、模板生成器、脚手架工具，本质上都在做同一件事：把代码作为输入，经过规则或统计模型处理后，输出一段更长的代码。补全工具尝试“接住你正在打的下一行”，脚手架按问答生成整个项目骨架，它们都尊重固定的边界——不会去动项目里的测试，不会自己决定换个实现方案，更不会在发现问题后折回去修前面的代码。这类工具是个“更好的键盘”，而不是“帮你做事的人”。

但“更好的键盘”有个玻璃天花板：它永远需要人来定义问题，并且只能在极小的上下文里生成文本。你磨了十几年数据集和神经网络，得到的也只是“在光标附近猜下一行”的能力。这也是为什么早期 AI 编程助手给资深开发者的价值感觉有限——对一个已经知道该写什么的人来说，补全只是省了打字；对不知道写什么的人来说，补全又帮不上忙。这个阶段一直持续到大模型出现，情况才真正松动。

1.2 任务型 Agent 的突破口：从“预测行”到“完成目标”

大模型带来的改变，其实不仅仅在生成能力。首先是“上下文理解”：它能容纳整个仓库摘要、issue 描述、历史决策。其次是“工具使用”：模型不再只是生成文本，而是可以通过调用接口去读取环境、修改文件、运行代码。两者叠加，第一次让机器可以围绕“目标”而不是“下一行 token”来运转。用一句直白的话来说：以前工具只关心“你正在写什么”，现在的 Agent 开始关心“你原本想达到什么”。

一个任务型 Agent 的工作循环大致是：接收目标、观察环境、制定计划、执行动作、检查结果、必要时修正计划，直到满足验收条件。举个例子：以前你让自动工具“给模块加一个异常处理”，它给你插入若干 try/catch；现在你只要说“让登录模块在数据库挂了时也能给用户一个友好提示，并且不要泄漏内部错误信息”，Agent 可能要先读登录模块代码、定位数据库连接点、设计前端提示文案、写代码、跑用例、甚至打开浏览器截图验证。这已经不是“输入代码输出代码”，而是“输入愿望输出结果”。我把新旧范式的主要差异整理成了一张表，方便对照看。

1.3 为什么“Coding Agent”这个名字失效了

“Coding Agent”这个名字失效，有三个很现实的原因。一是范围外溢：现在的 Agent 能做数据查询、文档产出、运维巡检、业务报表分析，代码编写只是其中一种工具操作，再叫“Coding”无异于刻舟求剑。二是交互主体变了：许多使用者根本不关心代码，他们描述业务痛点，要的是结果，是某个愿望被满足。三是技术栈变了：真正让 Agent 稳定工作的是工具链、验证体系、权限边界和评测集，这些和“代码生成”没有直接关系。

所以继续叫“Coding Agent”，就像把智能手机叫“打电话手机”——也没错，但严重低估了它的能力边界。我更愿意把它称做执行体，或者直接叫“许愿机”。许愿机是夸张的说法，但它准确抓住了核心语义契约：用户描述想要的终态，机器负责把中间路径走完。做系统的人要尽早把思维从“写代码助手”切换到这个契约上，否则很容易被历史命名锁住架构思路。

2. 许愿机核心引擎拆解：从模型调用到自动验收的技术内幕

2.1 一个最小 Agent 的四个层级

做 Agent 最容易踩的一个坑，是把它等同于“一个会调大模型的脚本”。真正能稳定完成任务的 Agent，至少由四层组成：模型层、工具层、执行环境层、记忆层。模型层负责推理和决策，决定下一步做什么；工具层暴露可操作世界的接口，比如读文件、改文件、跑命令、调接口；执行环境层给这些工具划定边界，避免它们破坏宿主系统；记忆层负责在长任务中保留关键上下文，不让系统“做着做着忘了最开始想干什么”。

模型层不是只要一个“最强模型”，而是要一个“能正确调用工具的模型”。根据我的落地经验，指令遵从和工具调用能力，往往比单纯的文本智能更影响任务成功率。工具层设计直接决定 Agent 能做到什么程度，工具描述不清晰、返回结果解析不严谨，再强的模型也会变成“高智商路痴”。执行环境层包含沙箱、超时、网络限制、资源配额，它是保证“跑了不炸”的最后防线。记忆层则决定了系统能不能从 5 分钟任务扩展到几小时的长链路任务。

任何 Agent 编排都能简化成同一个循环：

# 伪代码：任何智能体运行循环的最小结构 while not is_goal_achieved(): context = gather_context() # 收集当前状态 plan = call_model(context) # 让模型决定下一步 result = execute_action(plan) # 执行这个决定 update_context(result) # 把结果写回上下文

难点全在每一行的“实现质量”里：怎么判断目标完成了？怎么从工具结果里提取有效信号？上下文怎么裁剪才不会失真？后面几节我会逐个拆开讲。

2.2 工具调用：让模型从“会聊”到“会干活”

LLM 本身只是文本生成器，不具备直接操作系统能力。想让模型“干活”，就得提供工具。现代模型可以在输出中附带“我想调用这个工具”的结构化消息，系统解析后执行，再把结果回传给模型，循环往复。这其实很像一个只会出主意的顾问，配上了手脚齐全且有执行力的施工队，才真正开始动手解决问题。

工具定义里最容易被忽略的有两个点。一是描述要短而准。工具描述是给模型看的，不是给人看的，写一大段让人阅读的文档，模型反而不理解。二是返回消息必须结构化，要明确区分“执行成功但结果为空”和“执行出错”。我就见过一个系统把命令的错误输出当 stdout 解析，模型拿到一份看似正常的错误日志，还认为任务已经完成了。一个工具描述示例大概是这样的：

{ "tool": "run_shell", "description": "在项目沙箱中执行 shell 命令，返回 stdout/stderr 和退出码", "parameters": { "command": "string, 要执行的命令", "cwd": "string, 工作目录", "timeout": "number, 超时秒数, 默认30" } }

工具数量不是越多越好。每增加一个工具，就多一分“调用错工具”的风险。我的经验是以“覆盖任务闭环”为最小集：能读项目结构、能读文件、能改文件、能运行命令和测试、能访问外部接口；其余操作一律按需追加。多一个工具，测试矩阵就多一条分支，排查问题的复杂度也随之上升。

2.3 记忆与上下文管理：防止许愿机“失忆”

Agent 的失败有个常见共性：做着做着就忘了目标，或者被最新出现的报错带偏。原因很直接——上下文窗口有限，而任务运行过程中的信息在不断增长，系统必须主动做取舍。一个能撑起长任务的记忆体系，最好分成三层：核心目标、任务档案、领域知识。核心目标永远不被挤出上下文；任务档案记录已完成步骤、失败尝试、中间产物；领域知识包括项目结构、术语表、相关模块说明，适合放向量库或外部文件里按需检索。

实践里，与其依赖模型“从对话历史里自己总结”，不如设计显式的记忆结构。我见过的可行方案有很多，核心思路都是：在每个关键节点，用一个小模型把当前进展、剩余目标、风险项压缩成一份结构化摘要写回上下文，而不是无脑堆历史记录。另一个性价比非常高的做法，是让 Agent 在任务开始前先读取一份项目说明文件，里面只写全局结构、技术栈、常用命令、常见坑。这个文件的收益远大于堆更大上下文，因为它把最关键的领域知识放在最稳定的位置，而不是等 Agent 在代码里现找。

2.4 沙箱与权限边界：给愿望加一道“防火墙”

模型输出天然不可完全预测。同一个提示词，这次可能生成git checkout hotfix，下次可能生成git push --force；也可能陷入死循环，反复执行同一个命令。所以凡是涉及执行动作的许愿机，都必须有执行环境层的防护。防护并不等于是花大价钱搭整套容器云，个人项目和内部工具可以先从最简单的手段做起：把 Agent 的工作目录限定在一个临时目录、用低权限账号运行、给每条命令加超时和资源限制、限制网络出口。这些组合起来，能挡住绝大多数“乱跑”事故。

更精细的做法是权限矩阵。我强烈建议把工具按照操作危险程度分级挂起：

系统加入权限分级后，模型的工作流就要设计成“碰到高危操作先停下来问人”。这不是效率倒退，而是保证长期安全的必要成本。许愿机是会持续运行的，哪怕每次事故概率只有百分之一，累积跑一百次任务，就会变成大概率事件。

2.5 自动验证回路：许愿机凭什么叫“完成”

判断一个 Agent 是否完成目标，是整个系统中最容易被低估的部分。常见做法是“命令跑完没有报错就认为成功”，但命令能跑通和业务目标达成之间，隔着巨大鸿沟。比如“给登录模块加上密码强度校验”，编译能过、测试也能过，但真实用户提交弱密码时有没有提示，往往没人验证。没有验收环节，就会交付一堆“看起来完成了”的空壳。

更靠谱的验证应当分三层。最基础的是构建和测试，保证没有引入低级破坏；其次是契约或行为验收，把需求转化为可自动执行的检查项；最后是环境状态验证，比如确认迁移脚本执行成功、数据库结构符合预期、页面元素出现在指定位置。我最想强调的一个技巧是：让 Agent 在动手前先根据需求编写一份验收脚本，把“完成”的定义写死在交付物里。这样一来，用户拿到的不只是修改结果，还有一套“能证明修改是对的”的证据链。

3. 走向好用的工程化落地：选型、任务拆解与执行器细节

3.1 模型选型与任务匹配：先测基线，再谈上限

模型选择是许愿机工程化的第一步。新手容易直接选最大的模型，觉得能力越强越好；用过一段时间后，我发现这是性能和成本的双重浪费。不同任务对模型能力的侧重点完全不同：任务规划需要极强的理解和推理，代码改写需要精确的模式匹配，结果总结只需要中等语言能力。把复杂规划、工具序列决策、最终裁判交给更强的模型，把单调的局部修改、格式化、解释说明交给更轻量的模型，是现在比较稳定的分层策略。

更务实的做法是建立一个“标准任务集”当基线。我会挑 20 个代表性任务，覆盖规划、修改、工具调用、失败恢复、长任务这些场景，每次更换模型或调整提示词，先跑一遍基线看成功率。只看单次 demo 很容易被偶然性欺骗。基线还要记录失败原因，比如是计划错了、工具定义不清晰，还是模型本身理解错了。否则你会发现换了更高价的模型，成功率却纹丝不动，因为瓶颈根本不在模型上。

模型决策可以用一个简单矩阵来辅助判断：

3.2 计划生成与任务拆解：把“愿望”翻译成“路线图”

Agent 要完成模糊愿望，就必须先把愿望翻译成行动路线。这里我比较推荐“先计划、再执行”的流程：模型在动手前先输出一份结构化计划，系统校验格式正确后再逐节点执行。自由文本的“边想边干”在长任务里很容易漂移，结构化的计划反而好用，因为它可以被程序检查、记录和回滚。

一份计划至少要包含目标、步骤列表，以及每个步骤的预期结果。预期结果尤其重要，它是步骤“完成”的判据，也是回滚的依据。如果 Agent 修复了编译错误但测试仍失败，它应当知道下一步不是继续盲改，而是重新评估这个步骤是否真正完成。计划也需要允许 Agent 中途申请修改，因为环境信息常和初始假设不一致。常见处理是暴露一个“变更计划”工具，但调用时要带上原因，方便人审查。

计划生成的质量跟提示词的关系非常大。我反复使用的一句话是“不要解释你不知道的东西，列出你要验证的假设”，这句话能显著减少模型一本正经输出假步骤。实际项目里，我还会让计划在每一步绑定验证动作，比如完成一个大步骤就跑一次相关测试，而不是把所有验证留到最后。验证前置比验证集中更可靠，问题暴露得越早，定位成本就越低。

3.3 执行器设计：超时、补丁、日志和人工闸门

执行器是 Agent 操作环境的最终物理层，设计得好不好，直接决定事故率。执行器至少要负责四件事：给每个外部命令设置超时，防止单条命令卡死整个任务；把操作日志和 diff 完整记录下来，方便事后回放；限制变更范围，默认只允许在指定工作区内读写；在高危操作前加入人工确认闸门。

我最想强调的是“以补丁而不是直接改文件”的方式来呈现变更。Agent 每轮修改生成一个 diff，由系统暂存，后续验证通过后再真正落盘。这样做有两个明显收益：一是事故概率降低，验证不通过可以整体丢弃；二是人可以在关键节点快速 review，看大模型把整个文件重写，远不如看一个 diff 好判断它到底干了哪些事。

日志也要分层设计。Agent 的内部推理过程和每一步工具调用要分开记录：人审的时候，只关注工具调用结果和关键决策就够了，推理过程太多反而淹没问题。我把日志分为“调试日志”和“轨迹快照”两层：前者给开发期定位 bug，后者供审计和关键时刻回放。执行器如果能把每一步的环境指纹记下来，比如目录状态哈希、命令退出码、关键文件 diff，后续排查能省一半时间。

3.4 多角色协作：规划者、执行者与审查者如何分工

复杂任务里，我倾向于在同一系统里拆分多个角色：规划者负责读懂目标和制定路线，执行者负责具体操作，审查者负责验证结果。这种拆分不是噱头，核心目的是把“生成”和“验证”隔离，避免同一个模型既当运动员又当裁判。自己写完再让自己验收，模型天然会倾向于认为自己写得好，尤其当输出看起来很有道理时。

角色之间不需要各自独立的内存和模型，最简单的方式，是用同一个模型搭配不同的提示词和工具权限来跑不同角色。规划者不接触执行工具，执行者不拥有最终验收权，审查者没有修改工具，彼此靠结构化消息协作。这样做还有一个额外好处：每个角色更聚焦，输出更稳定，成本也更可控。如果任务复杂度不高，我建议从“单 Agent + 后置独立验收角色”开始，两个角色足以打破自产自销，通信开销也比四五个角色低得多。

3.5 数据飞轮：把每次成功与失败变成下一轮燃料

做过几轮 Agent 项目后，我最大的体会是：Agent 能力的提升，不是靠反复调提示词实现的，而是靠把运行过程中积累的数据变成体系。每个任务跑完，至少要把四类东西沉淀下来：任务描述、执行轨迹、最终结果、失败原因。尤其要重视失败数据，失败轨迹是改进系统最直接的信号源。

一个实用的闭环是：失败任务先自动归类原因，比如计划错误、工具错误、环境错误，还是模型理解错误，再针对高频失败类型做优化。如果大量失败是因为工具描述不准确导致模型传错参数，那改工具定义会比换更大模型更有效；如果是环境不稳定，就要先解决沙箱问题。我还会把成功案例中的高价值工具序列存成“经验片段”，在新任务里当示例用。这套数据飞轮跑起来之后，系统进步速度会明显超过每次都从零开始乱试的做法。

4. 能上线的三个真实场景实录：运维改造、数据问答与原型生成

4.1 场景一：某个电商后台的依赖升级“维修队”

第一个案例来自某个电商后台系统。老仓库的依赖链非常长，安全升级往往要跨多个模块，团队每个季度需要花两三周做升级和回归。我们最初的想法是用 Agent 做“自动改版本号”，但很快发现真正的瓶颈不在“改”，而在“升级引发的连锁报错”。于是目标改成了：Agent 自动读取依赖公告，在隔离分支上执行升级，跑构建和测试，如果失败就尝试修复，最后生成变更说明并开一个合并请求。

这里最关键的调整，是强制 Agent 不允许直接改主分支。所有动作都在分支上进行，合并请求必须由人 review。我们最开始没设这个限制，Agent 有一次把主分支直接回退到旧版本，差点酿成事故。设置分支隔离和一套简单的验收脚本后，单次升级的耗时从几小时缩短到十分钟以内，一个季度的升级工作从两周降到两三天。这个项目真正的价值不是“更快升级”，而是把人的注意力从重复劳动里解放出来，去检查那些机器难以判定的逻辑冲突。当时的一些运行参数也可以给读者参考：单次并行最多 3 个分支，单条命令超时 5 分钟，测试失败自动回滚。

4.2 场景二：给非技术团队用的“数据提问机”

第二个案例是给运营团队做一个数据问答系统，需求一句话就能概括：让不会写 SQL 的同事也能从数据仓库里取数。系统流程是接收自然语言问题 → 生成 SQL → 在只读数据源上执行 → 返回表格和一句文字结论。听起来不难，实际难点全在安全性和语义正确性。我们给数据源配置了只读账号、限制了查询返回行数、禁止了跨表更新删除等危险语法，模型生成的 SQL 必须先经过规则引擎校验才能执行。

更大的坑是语义错误。SQL 语法完全正确，但时间范围理解错了、把“流失用户”定义理解错了，导致返回的数字看起来合理，实际上是错的。后来我们把业务词汇表和一批示例 SQL 做成系统提示词，让模型回答前先参考这些“标准说法”，语义错误率才明显下降。这个系统上线后，日常取数需求减少了七成左右，团队成员不再排队等提数，自己问一句就能拿到初步结果。对这类系统，我最深的体会是：自然语言到 SQL 的转换里，最难的其实不是语句生成，而是把外部业务概念准确映射到数据模型上。

4.3 场景三：3 人团队用“需求即原型”做产品验证

第三个案例来自一个只有三人的小团队，想快速验证产品想法，但没有专门的前端工程师。我们给他们搭了一套“一句话生成原型”的系统：用户描述一个页面或功能，Agent 会在固定项目模板里生成对应组件，本地预览后自动部署到临时环境，生成一个可点击的链接。这套系统让团队在产品讨论阶段就能拿到可交互原型，比画图工具更有说服力，也比从零开发快得多。

实际跑下来发现，完全放开让 Agent 自由发挥，样式会非常随意，五颜六色也没有统一风格。改成“模板约束 + 局部改动”之后，才真正稳定输出。具体做法是：项目模板里预先设计好组件库和样式系统，Agent 只被允许在这些白名单组件之间组合参数，而不是自由写样式。这让原型不再“一眼 AI”，也让代码更可控、更容易被别人接手。这类系统最大的价值是降低了早期验证成本，让团队在投入正式开发之前，先把方向聊明白。

5. 六条 Agent 工程避坑指南：踩过才知道的细节

5.1 模型会表演勤奋，实际原地打转

看 Agent 的日志，它看起来一直在忙：执行命令、读文件、写文件。但仔细对比就会发现，它可能已经五次运行同一个测试、三次尝试同一个修复，目录状态却没有任何变化。这种“原地打转”是 Agent 项目最常见的失败形态之一，原因通常是没有有效信号告诉模型“当前方案不管用，换个思路”。解决办法是加一个“无进展检测”：连续几步的执行结果和目录状态哈希不变，就强制打断循环，让系统重新生成计划，或者换个更小的模型尝试。我在系统里加了这个检测后，长任务的失败率下降非常明显，因为模型不再有机会用大量重复步骤把上下文撑爆。

5.2 工具越强，事故越近

对 Agent 而言，危险的不是模型，而是你给了它什么工具。系统越强大，越要小心：每增加一个能删文件、改数据库、发布服务、对外发送消息的工具，事故概率都会明显上升。这些工具并不需要默认全开。我推荐的原则是“默认最小权限、只开放任务必需能力、危险操作显式授权”。工具权限矩阵要跟模型能力一起测试，换模型后也要重新跑一遍风险用例，别默认它一定还安全。

5.3 上下文越长，判断越钝

一开始做仓库级任务时，我们习惯把整个代码库读完再让模型动手，觉得信息越全越好。但后来发现，上下文过长时，模型的判断会钝化：它能记住大量细节，却在关键处失去重点，生成平庸的长篇修改方案。处理办法是分层加载：先用目录树和关键词搜索定位相关模块，再只加载局部文件；不必要的历史消息要用摘要替代，而不是一直堆着。把 Agent 的信息获取方式从“一次塞满”改成“按需检索”，准确度和速度都会上来。

5.4 自动验收比自动生成更重要

如果只能在一个方向投入，我会选择自动验收。一个没有验收的 Agent，只能证明它“跑完了一圈”，不能证明它“解决了问题”。而验收做得好的 Agent，哪怕生成能力平平，也能通过迭代逐步逼近正确结果。我之前接手过一个项目，Agent 生成的代码看起来都对，但业务方验收时发现核心逻辑根本没实现，原因就是验证只看了编译和测试覆盖率，没有检查行为目标。后来我们在每个任务模板里都预置了验收清单，要求 Agent 在交付前自证“每一条都通过”，效果立竿见影。

5.5 小模型做执行，大模型做裁判

成本优化的可靠路线之一，是小模型做执行，大模型做裁判。小模型生成速度快、成本低，但容易在复杂决策上跑偏；大模型负责评估小模型的结果、判断是否满足需求、必要时给出下一步指示。这种组合比“大模型做所有事”便宜，任务成功率不一定低，甚至因为视角不同而更稳。同一任务里，规划、执行、验收各自适合的模型能力不同，不必强求一个模型通吃。

5.6 人机分工：三件事不该交给许愿机

最后一条踩坑记录是边界问题。许愿机能力越来越强，但有三类事情我不建议交给它：价值判断、跨系统承诺、未知风险定责。比如“这个用户数据要不要删”“这个第三方接口能不能答应对方今晚上线”，这类决策会影响外部角色，机器无法承担。Agent 更适合做的，是把信息铺开、生成候选方案、执行已经验证过的动作。把边界和人工闸门预先画清楚，比信任模型的“自觉”可靠得多。许愿机不是用来取代人的，它是用来扩大人的决策带宽的——这是我做了多个 Agent 项目之后，最想强调的一句话。

6. 手把手搭第一台许愿机：从愿望定义到 8 步落地路线

6.1 最小许愿机的 8 步搭建路线图

很多人拿到 Agent 框架后，第一件事是跑官方示例，第二件事就是做通用助手，这其实是错误路径。搭第一台许愿机，我的建议是走这 8 步。一，定义一类愿望：选一个具体、重复出现、结果可验证的小任务。二，拆输入输出：想清楚用户提供什么信息、系统要产出什么结果。三，定义成功标准：把“完成”写成可自动判定的检查项。四，选模型和工具集：按任务匹配模型，工具只做最小闭环。五，实现编排循环：按第 2 章的最小结构搭一个能跑通的版本。六，加沙箱和权限：哪怕只是临时目录和超时，也要在第一天就加上。七，跑 20 个任务基线：记录失败原因，针对高频问题迭代。八，沉淀数据：把每次任务轨迹和失败归因存档，形成下一轮改进的燃料。

每一步做完，都不要急着加新功能，先让它在真实任务里稳定跑一周。比起做一个看起来很全的系统，我更推荐做一个只解决一类问题、但能稳定交付的系统。

6.2 一个 200 行 Agent 编排原型的长什么样

为了展示核心结构，我写了一个最小编排原型。代码省略了具体接口细节，重点在循环逻辑，实际开发时替换成你正在用的模型 SDK 即可。

# 最小 Agent 编排循环原型（伪代码，需替换为实际模型接口） def run_agent(goal, tools, max_steps=20, token_budget=8000): context = [{"role": "user", "content": goal}] step = 0 while step < max_steps: step += 1 # 1. 调用模型，允许返回工具调用意图 reply = call_model(context, tools) # 2. 如果模型只是输出文本，说明它认为任务已完成或需要询问 if not reply.tool_calls: return reply.text # 3. 执行模型请求的工具 for call in reply.tool_calls: result = execute_tool(call.name, call.arguments) # 4. 控制结果大小，避免撑爆上下文 result = truncate(result, max_chars=2000) context.append({ "role": "tool", "tool_call_id": call.id, "content": result }) raise TimeoutError("max steps exceeded")

这段代码只有十几行，背后却涵盖了 Agent 的核心循环。工具定义和模型接口可以从任意兼容 API 接入。真正需要在execute_tool里实现的，是超时、目录隔离、结果结构化这些细节。模板里的token_budget也可以根据自己的情况调整，用来限制单次任务的上下文规模。

6.3 第一台许愿机适合接什么“愿望”

选第一个愿望时，我有四个标准：频率高、错误成本低、结果易验证、数据可积累。符合标准的示例有很多，比如“把 Markdown 写作规范检查自动化”“把 bug report 转化为可复现的测试用例”“把 API 变更自动补齐 mock”“把周报素材整理成要点列表”。这些任务看起来不如“写代码”那么酷，但正因为边界清晰，才适合用来打磨 Agent 的骨架。等这套骨架在不同任务里都稳定了，再往更复杂的场景扩展。

第一次做出一个能自己“跑测试、改代码、再跑测试”的小 Agent 时，我心里其实不是爽，而是慌——当工具开始自己验证目标时，人对需求的定义就得比平时精确得多。许愿机这条路，最难的从来不是选模型、调工具，而是你终于要说清楚自己到底想要什么。所以我建议所有打算做这类系统的团队，把第一周的时间花在定义愿望上，而不是搭框架。好的许愿机，往往从一句精确得近乎冷酷的需求描述开始。就冲这一点，我也觉得 Coding Agent 这个旧名字，配不上它正在成为的东西。