2026 年我作为资深工程师如何使用 LLM Agent：从副驾到主驾的真实工作流转变

从副驾到主驾，2026 年资深工程师的 LLM Agent 实战工作流：哪些交给 Agent，哪些必须自己做。
原文链接：AI 小老六

一年之差：Agent 从「勉强能用」变成了「几乎离不开」

2025 年初，行业里最强的推理模型还是 OpenAI o1，​Agent 大多数时候只能跑两步就被上下文压垮​。一年多过去，我使用 LLM 的方式已经发生了根本性的变化。

去年我还主要用 LLM 做「智能补全」、「一次性研究脚本」、「陌生领域的小修小补」；今年，我几乎每一次代码改动都会先从 Agent 起手，​PR 也经常由 Agent 起草、人工把关一遍后再提交​。这个转变不是「工具更顺手了」那么简单，它意味着工程师的工作位置被推向了上游 —— 从写代码的人，变成了判断、调度与验收 Agent 的人。

下面这张表是我对自己使用边界变化的整理，它比任何宏大叙事都更能说明 2026 年 ​Agent 的实际渗透程度​：

工作类型	2025 年的做法	2026 年的做法
熟悉领域的完整 PR	不交给 LLM，自己写	全部由 Agent 起草，编辑一遍后提交
跨仓库改动	多个 VSCode 窗口手动协调	Copilot CLI / Copilot App 同时跑多个 Agent 会话
Bug 排查	偶尔丢给 LLM 试一试	每个 Bug 都先开 Agent 会话，约 80% 能直接定位
大型代码库的研究	自己读代码、问同事	Agent 跨仓库检索，错了也容易看出来
测试 / 本地环境配置	让 LLM 写 curl 脚本，自己跑	直接交给 Agent 跑，看日志
PR 描述 / ADR / Slack	自己写	仍然自己写（极琐碎 PR 除外）
博客文章	自己写，LLM 校对	自己写，LLM 校对
UI 测试	自己测	仍然自己测（Agent 对视觉细节不敏感）

图：从副驾到主驾 —— 写代码这件事不再是工程师亲自完成，而是由我来判断、调度和验收 Agent

Agent 真正变好的几个信号

这种「变好」具体体现在三件事上：

• ​失败后能自我恢复​：早期 Agent 一旦走偏，就需要人工随时干预、暂停、重新引导；现在的 Agent 推进速度过快，其实很难、也没必要逐步盯着，因为它大多数时候能自己把方向修正回来。
• ​跨仓库视野带来的诊断能力​：当 Agent 能同时看到多个仓库时，它在排查 Bug 上的「信息半径」远远超过人类点开 IDE 一个窗口能覆盖的范围。
• ​试错成本变得很低​：我经常会让 Agent 跑 5～6 次，全部拒绝再让它重来，平均每次只需要 30 秒判断「这是不是我要的方向」。这种「高频拒绝 + 偶尔接受」的工作模式，是 2025 年完全不可能的。

但我也不会把 Agent 抬上神坛。最近我遇到一个棘手 Bug，前后跑了十几次 Agent 会话才最终定位。期间真正起作用的，不只是 Agent 本身，还有我不断补充上下文和收窄搜索空间的过程：

• 从日志、Slack 中收集额外上下文，再喂给 Agent；
• 在脑子里建立自己的故障模型；
• 自己搭一个独立的复现环境；
• 看到 Agent 的猜测不对，明确告诉它「你的假设不成立，因为 X」，或者直接终止、带着新提示重启。

最终虽然是 Agent 找出了 Bug，但这次「破案」我仍然会算作自己的工作成果 —— 因为正是我把搜索空间收窄到了 Agent 能够解决的范围。这也是我现在越来越确定的一点：​人类的专业判断，依然是 Agent 调试体系里的真正稀缺资源​。

图：30 秒拒绝 + 持续收窄搜索空间，是工程师在 Agent 时代真正稀缺的能力

一个清晰的「交还是不交」分配原则

我现在会用一个简单的决策流程来判断一项工作该不该交给 Agent：

图：Agent 工作分配决策流程 —— 哪些工作可以放心交给 Agent，哪些必须自己来

这套流程背后的真正信号是：​工程师对外的「署名性产物」必须自己写​。亲手写 PR 描述是在向 Reviewer 传递一个信号：「我已经认真审过这次改动，你不是第一个看 diff 的人。」

把测试和琐事尽量塞给 Agent

另一个很重要的变化是：​测试代码现在是廉价的​。

• 只要能避免 flaky，我都会顺手让 Agent 把测试补上；
• 单测可以让 Agent 先写，我做的是「挑明显错误」的快速复审；
• 集成测试也可以主动让 Agent 加；
• 跑通一次手动验证（curl / 接口调用）可以直接交给 Agent，自己看日志即可。

类似地，本地环境出问题 —— 比如 nvm 切不过去 Node 版本 —— 我也不会再第一时间去 Google，而是直接打开命令行 Agent，让它自己运行命令排查、修好。这件事的本质是：​Agent 已经替代了「在终端里查文档 + 试错」这一类高频低价值劳动​。

图：把跑测试、查日志、捣鼓本地环境这类高频低价值劳动尽量交给 Agent

真正的新核心技能：找到「不过度也不欠用」的那个平衡

如果要用一句话概括当下最重要的 ​AI 使用能力​，我会这样说：

把尽可能多的工作转交给 Agent，但不要走过头。

我观察到很多团队成员其实处于两种失衡状态之一：

• ​欠使用​：不让 Agent 调 Bug、不让它跑测试、连最琐碎的脚手架任务也要自己写；
• ​过度使用​：把对外沟通、需要细致评审的大改动也整段交给 Agent，事实上把判断责任也外包了。

这两种失衡都在浪费 Agent 时代真正的杠杆。今天的工程师价值，正在从「我能不能写出来」转向「我知不知道哪些工作必须自己做、哪些可以稳妥地交出去」。换句话说，​Agent 让「会判断」比「会写代码」更值钱​。

给国内工程师的几点直接借鉴

把这套经验落到日常研发场景里，至少有几条是可以马上试的：

1. ​每个 Bug 都先开一次 Agent 会话​：哪怕只是为了快速排除最常见的 80% 问题，也比直接埋头读栈要划算得多。
2. ​跨仓库探索优先用 Agent​：让它在多个仓库里「读一遍」再告诉你某个调用链是怎么打通的，比自己点开五六个 IDE 窗口高效太多。
3. ​测试覆盖率不再是奢侈品​：既然 Agent 写测试几乎零成本，那「要不要补这条测试」的犹豫就没必要再有。
4. ​PR 描述、设计文档、群里的关键沟通仍然要自己写​：这是你在团队里建立信任和判断力的方式，不要把这部分外包。
5. ​训练自己「30 秒拒绝」的肌肉​：看 Agent 输出第一眼就要判断方向对不对，错了立刻拒掉重来，不要被它的流畅度带着走。

Agent 已经从一个值得「试一试」的玩具，变成了每天要打开几十次的主战工具。但工具越强，越要警惕一件事 —— ​真正稀缺的不是会用 Agent 的人，而是能在 Agent 面前保持判断力的人​。