Agent之HarnessEngineering：从“先别用聊天机器人写代码”到“持续让 agent 在后台运行”：一位软件工程师的 AI 采用之路、任务拆分与自我复现实践、下班时段代理任务、外包高确

Agent之HarnessEngineering从“先别用聊天机器人写代码”到“持续让 agent 在后台运行”一位软件工程师的 AI 采用之路、任务拆分与自我复现实践、下班时段代理任务、外包高确定性工作、harness engineering 设计方法以及如何把 AI 变成可验证、可回滚、可持续交付的真正生产力工具导读这篇文章讲的是作者如何从“讨厌聊天机器人式 AI”逐步走到“让 agent 成为日常工作伙伴”的全过程先认清聊天框的低效再通过复现自己的工作理解边随后把适合的任务、适合的时段和适合的验证机制结合起来最终形成一套以 harness engineering 为核心、可持续提升效率的 AI 工作流。这篇文章讲的不是“AI 到底好不好”而是“一个软件工程师如何一步步把 AI 变成真正可用的生产力工具”。作者的路线非常清晰先停止迷信聊天框再通过复现自己的工作认识 agent 的边界然后把碎片时间、夜间时间和确定性高的任务交给 agent最后通过 harness engineering 把错误变成规则、把规则变成工具、把工具变成稳定流程。整篇文章的核心启发是AI 的价值往往不在于单次回答有多惊艳而在于它是否能够在正确的工作流中持续地、低摩擦地、可验证地帮助你完成工作。 背景痛点● 聊天框效率低作者最初明确认为拿聊天界面直接做有意义的编码工作效率很差因为模型大多是在“猜”训练中学过的答案而人类却要反复指出错误、来回复制代码和命令输出整体摩擦远高于自己动手。● 现有项目更难用在 brownfield 项目里作者发现聊天式 AI 的输出经常不理想尤其在需要结合已有代码库、真实上下文和工程约束时反复修补比自己直接做还费时。● 早期试用难以建立信心即使出现过“哇”的时刻比如把截图交给 Gemini 复现命令面板作者很快也发现这种成功很难稳定迁移到其他任务导致一开始对 AI 工具并不信服。● 任务边界不清很多初期任务之所以让 agent 表现差是因为问题被塞进了一个过大的 session 里没有先拆成清晰的小任务、规划与执行也没有让 agent 有办法自我验证。 具体的解决方案● 从“聊天机器人”转向“agent”作者认为真正有价值的不是聊天式 AI而是能在循环中调用外部行为的 agent至少要能读文件、执行程序、发起 HTTP 请求才算具备干活能力。● 先复现自己的工作作者强迫自己先手工完成再让 agent 复现同样的提交以此建立对 agent 能力边界的真实理解并逐渐摸清哪些任务适合、哪些不适合交给 AI。● 用收工时间跑 agent他把每天最后 30 分钟专门留给 agent让它在自己无法继续工作的时间推进研究、分类、预处理等任务把“有空时多做”改成“没空时也能推进”。● 外包高把握任务当他足够熟悉 AI 擅长的模式后就把那些几乎肯定能做对的任务交给 agent自己继续做深度思考或更需要创造力的工作。● 工程化 harness他把“让 agent更快知道自己错了没有”称为 harness engineering做法包括改进 AGENTS.md 这类隐式提示以及编写截图、过滤测试等实际工具让 agent更容易自证正确。● 让后台始终有 agent 在跑作者进一步把目标提升为“尽量任何时候都有一个 agent 在运行”只在真正有价值的任务上才启动它而不是为了运行而运行。 核心思路步骤● 第一步接受聊天式编码的局限作者先从失败经验中得出结论聊天界面适合日常辅助但不适合承担主要编码工作因此必须切换到能执行动作的 agent 形态。● 第二步通过“做两遍”建立判断他刻意把手工提交和 agent 提交都做一遍从第一性原理上理解agent 的优点、缺点和适用范围而不是只看演示或听别人评价。● 第三步把大问题拆成小 session对于模糊需求先规划、再执行对于复杂任务不做“一个超大 session 画整只猫”而是拆成可操作的小块。● 第四步把可验证性前置给 agent 一套能检查自己是否做对的工具和流程让它更容易修正错误、减少回归而不是等人类最后兜底。● 第五步选择合适时段让 agent 工作在白天保留自己的深度思考时间在临近收工或无法专注时把研究、triage、并行尝试等任务交给 agent。● 第六步持续改造工作流一旦发现 agent 做错就把错误转化为规则、提示或工具尽量让它以后不再犯同类错误同时也让它能更稳定地证明自己做对了。● 第七步控制打断节奏作者特别强调关闭 agent 桌面通知避免 agent 主动打断人类更合理的方式是由人类在自然空档主动检查。 优势● 提升整体效率当 agent 被放到合适的任务和合适的时间段里它可以在用户不方便工作的时段继续推进让“空闲时间”变成生产力。● 降低重复劳动通过先复现自己的工作、再让 agent 做同类任务作者逐渐减少了大量手工复制、粘贴、修补和试错的无效劳动。● 提高任务命中率把高确定性的任务外包给 agent可以让它在自己擅长的边界内稳定产出而人类则把精力留给更复杂、更有创造性的部分。● 形成可持续工作流AGENTS.md、脚本工具、筛选测试和反馈机制共同构成了一套可持续的 harness使 agent 的价值不是一次性的而是随着迭代不断累积。● 兼顾效率与技能成长作者认为把重复性任务交给 agent 并不会让人完全停止成长因为人类仍可保留并持续训练自己真正擅长且热爱的任务。 结论和观点侧重经验与建议● 不要迷信聊天框真正能带来效率的不是“跟 AI 聊”而是让 AI 进入可执行、可验证、可循环的 agent 工作流。● 先理解边界再扩大使用作者是在反复失败后才真正摸清 agent 的能力边界这提醒我们判断工具价值不能只看亮点演示也要看真实项目里的稳定性。● 拆任务比硬扛更重要复杂任务要拆成清晰的小 session模糊任务要拆成规划与执行两个阶段否则 agent 很容易在一团乱麻里迷失。● 验证机制比“聪明”更关键只要能让 agent 快速知道自己错了它往往就能自我修正因此工具和约束比单纯提升提示词更有效。● 把 agent 用在最合适的时段下班前、精力下降时、适合研究和 triage 的任务是 agent 的高收益使用场景不要试图让它替代所有思考。● 让工具服务于你而不是你服务于工具关闭通知、控制打断、筛选高价值任务核心原则是由人类掌控节奏而不是被 agent 的存在反向牵引。● AI 采用是一条长期演化路径作者把自己的心态从怀疑、勉强接受、局部使用推进到如今的稳定依赖但仍保持谨慎和尊重不同选择的态度。目录从“先别用聊天机器人写代码”到“持续让 agent 在后台运行”一位软件工程师的 AI 采用之路、任务拆分与自我复现实践、下班时段代理任务、外包高确定性工作、harness engineering 设计方法以及如何把 AI 变成可验证、可回滚、可持续交付的真正生产力工具一、整体脉络核心要点经验技巧Step 1: Drop the Chatbot核心要点经验技巧Step 2: Reproduce Your Own Work核心要点经验技巧Step 3: End-of-Day Agents核心要点经验技巧Step 4: Outsource the Slam Dunks核心要点经验技巧Step 5: Engineer the Harness核心要点经验技巧Step 6: Always Have an Agent Running核心要点经验技巧Today核心要点经验技巧从“先别用聊天机器人写代码”到“持续让 agent 在后台运行”一位软件工程师的 AI 采用之路、任务拆分与自我复现实践、下班时段代理任务、外包高确定性工作、harness engineering 设计方法以及如何把 AI 变成可验证、可回滚、可持续交付的真正生产力工具地址《My AI Adoption Journey》文章地址https://mitchellh.com/writing/my-ai-adoption-journey时间2026年2月5日作者Mitchell HashimotoHashiCorp联合创始人一、整体脉络作者把自己采用新工具的一般过程概括为三个阶段先经历低效期再进入“可用但平庸”的阶段最后才会真正形成改变工作流和生活方式的发现期。本文就是他从“AI 很难用”逐步走到“AI 已经成为稳定工作方式”的全过程记录。核心要点作者的态度不是“拥抱或反对 AI”的立场宣言而是一个偏实践、偏验证、偏效率的工具使用者视角只有当 AI 能在真实工作里持续节省时间、减少摩擦、并且不强迫人类频繁纠错时它才算真正有价值。经验技巧不要把 AI 当成先天就能替代人的“万能聊天机器人”而要把它当成需要被设计、被约束、被验证的工作伙伴真正的收益往往来自工作流设计而不是单次对话的惊艳程度。Step 1: Drop the Chatbot第一步的核心结论非常直接不要再试图通过聊天界面完成真正有价值的编码工作。作者认为聊天式交互虽然在某些演示场景里能给人“哇”的感觉但在现实代码工作中效率很低因为你总是在“让模型猜答案—再不断纠错”的循环里消耗时间。核心要点作者承认自己第一次接触 AI 编码时曾被震撼例如把 Zed 命令面板截图交给 Gemini让它用 SwiftUI 复现结果非常接近目标但在 brownfield 项目里他很快发现聊天界面经常产出不理想结果而且来回复制代码和命令输出本身就极其低效。经验技巧真正有价值的不是“聊天”而是“agent”一个能循环聊天并调用外部行为的 LLM。至少要具备读文件、执行程序、发起 HTTP 请求的能力才开始接近能干活的工具。Step 2: Reproduce Your Own Work这一阶段作者开始强迫自己用 agent 重做自己手工完成过的提交通过“先手工做一遍再让 agent 复现一遍”的方式验证 agent 在真实任务中的能力边界。这个过程虽然痛苦但帮助他建立了更扎实的第一性原理理解。核心要点作者最初对 Claude Code 并不满意因为大部分输出都要自己修补效率还不如亲自做。为了确认问题到底在哪他故意把同样的工作做两遍自己先完成再让 agent 在看不到人工答案的情况下重做。通过这种方式他总结出三条关键认知任务要拆成清晰、可执行的小 session模糊需求要拆成“规划”和“执行”两个阶段如果给 agent 提供自我验证手段它更容易自己修错并避免回归。经验技巧这一步最重要的经验不是“AI 能做什么”而是“AI 不该被用来做什么”。当某类任务大概率会失败时主动不要使用 agent本身就是一种效率提升。作者还强调理解边界比盲目乐观更重要。Step 3: End-of-Day Agents作者开始尝试一种更符合实际节奏的模式每天工作结束前的最后 30 分钟把一些任务交给 agent让它在自己离线时推进。这个思路的本质是不是试图在“我有时间的时候”做更多而是把一部分工作转移到“我没时间的时候”完成。核心要点他最初对这种方式仍然不满意但很快发现几类工作特别适合放到晚上跑一是深度研究比如调查某个语言里所有符合条件的库并生成带优缺点、活跃度、社区口碑的长报告二是并行尝试一些模糊想法哪怕不一定产出可交付成果也能帮助第二天发现未知问题三是 issue/PR 预筛与分类尤其借助 GitHub CLI 做大批量 triage只看报告而不让 agent 直接回复。经验技巧作者没有走到“通宵循环跑 agent”的极端而是把它用作一种“下班前种下种子、第二天带着结果接力”的机制。这样既避免了长时间盯守又能在早晨获得一个 warm start提高进入工作状态的速度。Step 4: Outsource the Slam Dunks当作者对 AI 的能力边界足够清楚后他开始把那些“高把握、低风险、几乎肯定能正确完成”的任务直接外包给 agent自己则继续做别的更需要人类深度思考的工作。核心要点他的做法是每天先看前一晚 triage agent 的结果从中挑出那些 agent 几乎肯定能处理好的任务然后让 agent 继续独立推进但仍然保持“一次只跑一个”而不是并行一堆。与此同时他自己不会被社交媒体或视频打断而是继续进行正常的、原本就擅长的深度工作。作者特别强调要关闭 agent 桌面通知因为频繁切换上下文非常昂贵应该由人主动选择何时打断 agent而不是反过来。经验技巧他认为这种安排还能部分回应外界关于“AI 会削弱技能形成”的担忧当你把自己最不想做、但适合机器做的任务交给 agent 时你仍然可以在自己真正擅长且热爱的工作中持续训练技能。也就是说外包不代表停滞而是把注意力重新分配给更值得人类做的部分。Step 5: Engineer the Harness这一部分是全文最关键的转折。作者认为agent 要高效最重要的不是“更聪明地猜”而是“更快、更高质量地知道自己错了没有”。因此他把这种围绕工具、反馈、约束来提升 agent 成功率的实践称为 harness engineering。核心要点作者把 harness engineering 分成两类第一类是“更好的隐式提示”例如用 AGENTS.md 告诉 agent 不要总跑错命令、不要总找错 API第二类是“真正编程化的工具”例如截图脚本、过滤测试脚本等并且常常和 AGENTS.md 配合使用让 agent 既知道规则也有办法自行验证。作者还说他现在的做法就是一旦 agent 做错就尽力工程化地避免它再犯同样错误反过来一旦 agent 做对也要尽力让它能稳定证明自己做对了。经验技巧与其反复手工救火不如把失败模式沉淀成长期机制把错误变成提示把提示变成工具把工具变成可验证流程。这样 agent 的收益才会随着使用次数而增长而不是每次都重新踩坑。Step 6: Always Have an Agent Running在“工程化 harness”之外作者还给自己设了一个更激进但很实用的目标尽量保证任何时候都让某个 agent 在后台运行。只要 agent 没在跑他就会问自己现在有没有什么事情可以交给它核心要点作者喜欢把这个目标和较慢但更细致的模型一起使用比如 Amp 的 deep mode。虽然这类模型通常要花30 分钟以上做很小的改动但它们往往能给出很好的结果。与此同时他目前并不想同时运行多个 agent因为单 agent 已经足以在“我做喜欢的深度工作”和“我让机器人做我不想做的杂务”之间取得平衡。经验技巧这个目标现在还没有完全达成作者自评大约只能在普通工作日的 10% 到 20% 时间里维持后台 agent 运行。但关键不是“为了跑 agent 而跑 agent”而是要持续改进自己的工作流和工具让自己始终有足够高质量的工作可分配出去。Today在文章的当前阶段作者认为自己已经找到了一种相对稳健、克制、并且对他来说有效的 AI 使用方式既不盲目吹捧也不把 AI 神化而是把它当作一套能实际提升生产力的工具系统。核心要点作者明确表示他对 AI 的未来并不执着于某种立场他更关心的是“是否能持续帮助自己构建东西”。他也承认这个领域变化极快今天的认知很可能很快就会过时但对他而言持续成长、持续修正认知才是更重要的事情。经验技巧作者特别强调他不是来“劝服别人必须使用 AI”的每个人都可以有自己的选择。对他来说这篇文章更像是一种个人经验分享如何在快速变化的新工具面前保持审慎、实践导向和可持续的学习姿态。