工程师如何用好Coding Agent

人的职责

Coding Agent越来越能端到端推进任务，但它不会自动保证工程结果。模型越强，人的职责反而越聚焦：任务前要把目标、上下文和边界说清楚；任务中要知道什么时候让Agent自主推进，什么时候该停下来确认；任务后要能验收、审查、复盘，并把经验沉淀到下一次任务里。

从设计提示词转向设计任务

提示词只是载体，真正要设计的是任务本身：

要达成什么目标
相关背景和上下文是什么
当前环境中有哪些工具/能力/权限可用
有哪些限制、边界和偏好
满足什么条件、通过哪些验证才算完成

其中，上下文要分层投放：哪些直接给，哪些通过工具按需获取，哪些沉淀到skill/文档/进度文件里，避免一次性塞入太多低信号信息。

很多失败是任务本身设计得太松，而非Agent能力不足。这会让Agent看起来“很努力”，最后却交付一个不可用的结果。

工程素养依旧关键

AI降低了写出代码的门槛，但工程素养比以往更重要。

当任务里没有明确偏好和风险边界时，即便使用SOTA的模型和脚手架，Agent也容易选择局部、保守、能尽快通过当前任务的改法，而不是主动承担重构成本。因为局部最小补丁更容易让本次任务成功；重构会增加耗时，可能触及授权范围之外的逻辑，还会引入新的失败点。

所以要明确偏好：

线上业务：优先保守，保证兼容、可回滚。
原型验证：允许删除历史包袱，优先跑通关键路径。
长期维护模块：尽量贴近项目已有模式，必要时先重构再实现。
重构风险较大：先给plan，不要直接改。

另外，Agent达成目标后，专门追加一轮收敛：删掉多余代码、检查异味、补测试、确认结构是否贴近项目习惯。

如果把“能跑”直接当成“可合入”，Agent只会让坏实践更快进入代码库。

Harness会影响上下限

可以粗略理解为：Agent = Model + Harness。模型只是大脑，Harness是全部外围设施：脚手架、环境、上下文、工具、命令执行、状态记录、权限控制与结果验证。Agent的下限取决于输出能否被验证，上限取决于能托付多复杂的任务。

人的工作应该从实施转向构建Harness，让真实系统对Agent可读：架构文档、代码、测试、日志、截图、应用状态、指标。如果Agent看不见，就等于不存在。

最基础的Harness，是给Agent一个真实可执行的本地代码环境：它可以修改代码、安装依赖、编译、lint，并运行单元测试。这样模型的输出能被即时验证。

进一步，把验证从代码层面推进到产品层面：比如Web应用，可以给Agent提供Playwright CLI和浏览器，让它启动本地服务，像真实用户一样完成端到端验证；再配合截图、日志，去判断结果是否符合预期。

更进一步，还应该留下可审计轨迹：关键决策、失败尝试、测试证据、成本和人工介入点。否则失败时，很难做有效归因。

风险边界也很重要：Agent一旦拥有shell、文件系统、MCP或内部CLI，外部返回的内容都可能带来提示词注入或误导上下文。因此，高危命令、生产数据、删除/发布等高影响操作，都应该默认需要沙箱、日志和人工确认。涉密信息需要更加谨慎，因为即使Agent只有只读权限，信息也会被发送给模型推理提供方。

推进长程任务

长程任务有效的核心在于状态维护，以及每一轮都有验证和收敛：

必须有一个主成功条件，同时定义失败/预算/安全/人工接管条件
每轮都要留下分析、计划、实施、验收的可观察结果
验收过了才提交；触发接管条件时，就回滚/停下让人接管
可以利用子Agent隔离探索或review，但要给清楚边界和仲裁标准

把目标、计划、关键决策、当前状态、验证结果和未解决问题外部化到文件、issue、PR或任务系统里，避免上下文压缩导致关键信息丢失。适当地结合Hook（例如Codex/Claude Code的goal模式，在每轮结束时核对目标、驱动下一轮），让Agent能持续推进长程任务。

复盘要看轨迹

Agent能端到端交付以后，人很容易只调度、不看过程。时间久了，自己会退化成路由器：不再熟悉代码库，不再练习定位问题，也慢慢失去判断产出优劣的能力。

Agent的轨迹是很好的学习材料：

它怎么缩小问题范围？
它卡在哪个点？是否被错误上下文或低质量返回误导？
它有没有比人更高效的探索路径？

任务失败时，分析到底是缺了什么：上下文？验证方式？权限边界？还是Harness的其他部分？缺了什么就补什么。

正确使用子Agent

子Agent的价值是把可拆解、可隔离的工作放到独立上下文里并行执行。一是节省主Agent上下文，避免频繁的上下文压缩，主线只保留决策所需的摘要和证据；二是降低Agent自身的偏差积累，避免把整个任务越带越偏。

适合使用子Agent的任务，通常是可并行、结论可独立核对的工作，典型如探索、审查、分析。写操作则最好隔离或者保持单线程。

一个实用模式是：

主Agent明确问题、边界、输出格式和仲裁标准
子Agent A / B 独立探索或审查，先不要互相看结论
A / B 分别产出报告到文档：结论、证据、风险、未确定项
主Agent对比两份报告，汇总分歧，要求补证据或复查关键点
主Agent按验收标准做最终裁决，必要时交给人确认

skill/工具不是越多越好

工具和skill都会进入Agent的行动空间：有名称、描述、参数和参考材料。它们提供能力，也消耗上下文和注意力。

如果把能想到的都包成skill/工具，结果往往是功能重叠、命名相近、触发条件模糊。轻则多绕几步、反复试错；重则选错工具，被过期知识误导，或者被两个互相冲突的规则拉扯。

应该围绕任务提供最小可用能力集：

这个任务真正需要哪些能力
哪些工具/skill应该默认可见
哪些需要明确触发
哪些低频、冲突或不可验证的skill应该禁用/删除
工具返回是否高信号、可验证、可审计

好的工具是面向Agent设计的行动接口：命名清楚、输入明确、返回高质量信息，避免一次吐出大量无关数据。

主skill文件应该尽量短，只放触发条件、关键流程和决策入口；长参考、脚本、模板和领域细节，通过文件按需加载。团队级别的配置里，宁愿提供少量经过验证、边界清晰、能稳定触发的skill，也不要维护一个庞大但无人负责的skill库。此外，不要盲目信任外部skill，如果skill中有恶意指令，会有非常大的安全隐患。

过期的skill是负债

重复多次的任务模式，值得在一次完整执行后沉淀成skill。但不应该把一大段提示词直接堆到SKILL.md中，真正有用的是本项目的具体事实：

工作流程是什么
常见卡点有哪些
哪些地方必须让人确认
是否包含脚本/外部资源
适用触发条件和不适用场景

生成skill后，也不要默认它可靠。最好开一个不带隐性上下文的干净对话，重新跑一遍任务。

如果Agent在同一个失败路径上反复兜圈子，就说明skill缺少必要的禁止项、边界或恢复方式。

要及时更新skill，过期skill比没有skill更危险，因为它会用一种看起来很有经验的方式，把Agent带向错误路径。

方法论有保质期

应该持续体验最先进的模型和Harness，因为Agent能力会反过来改变任务设计方式。不知道边界在哪里，就设计不出更深的任务，也不敢尝试更激进的用法。适当拉长任务、观察Agent能自主推进到哪一步，是校准边界的方式。

这几年变化很快：从代码补全、问答，到实现简单需求，再到处理复杂工程任务，甚至在不少低风险业务场景里，口述需求也能推进。Spec-driven development逐渐成为一等公民，人的工作也越来越多地转向制定spec、约束和验收标准。

几个月前必须写进skill的步骤，今天可能不必显式声明。比如“写代码前先思考”“写完要跑单测”这类内容，如果已经被模型内化，被Harness或项目规则固化，就没有必要反复写在skill里；“必须先复述需求”“必须列五步计划”这类仪式模板，在强模型上反而可能限制探索空间。

使用者应该判断：这件事是一句话就能做，还是需要定plan/需要长程多阶段推进，需要设计怎样的Harness，以及需要多强的模型。

自荐一个反其道而行之的实践：https://github.com/Azure99/ultra-goal/blob/main/README_cn.md，最大限度地放手，让Agent自主达成任务目标。（适合于0-1的原型搭建、可行性验证等场景）

常用场景

• 理解新模块：让Agent画目录地图，标注入口、关键命令和核心数据流，并给出阅读建议。
• 新功能开发：先拆边界和接口契约，找相似实现，尽量复用项目已有模式，再写验收用例。
• 维护文档：改代码后，同步文档、总结变更说明。常见问题也可以及时整理。
• 代码Review：很适合拦截空值、边界条件、测试缺失、权限遗漏等问题。架构判断、业务语义和责任判断，仍然应该由人把关。
• Bugfix：让Agent先复现问题，再补失败测试，最后修复。完成后要求它总结根因、影响范围、修复前后日志和验证证据。
• 补测试：先让Agent学现有测试风格，再覆盖边界条件和异常路径。
• 重构：先定义“不改变外部行为”的验收标准，必要时先补测试，再小步提交。可以让子Agent专门做兼容性review。

归根到底，Agent时代的工程师仍然要对结果负责，只是杠杆从亲手写每一行代码，转向设计任务、构建Harness、设定边界和验证交付。