AI Agent 和程序员的工种之争
不卖课、不贩卖焦虑、不搞成功学。这篇聊聊 AI Agent——不是那种"未来已来"的营销文，而是我实际用了几个 agent 框架之后的真实感受。结论可能跟你想的不一样。
先澄清一个误解
很多人把 AI Agent 理解成"能自动完成任务的 AI"。这个理解不能说错，但太粗糙了。
更准确的说法是：AI Agent 是一个能自主规划步骤、调用工具、根据反馈调整策略的 AI 系统。它跟普通的 AI 对话的区别在于——你不需要一步步告诉它怎么做，你只需要告诉它要什么结果，它自己想办法。
听起来很美好。但实际用下来，你会发现一个尴尬的现实：Agent 在简单任务上显得多余，在复杂任务上又力不从心。
写个脚本？你直接跟 ChatGPT 说一声就行，用不着 agent 框架。做一个完整的全栈应用？agent 目前还做不到。agent 真正有用的场景，在这两个极端之间——那些需要多步操作、需要根据中间结果调整策略、但又不至于复杂到需要人类深度参与的任务。
举个例子。"帮我把这个目录下所有的 .js 文件重命名为 .ts"——这种任务不需要 agent，一条 shell 命令就搞定了。"帮我把这个项目从 JavaScript 迁移到 TypeScript"——这种任务 agent 也搞不定，因为你需要做大量的架构判断。
但"帮我把这 50 个文件的类型定义补全，如果有不确定的地方先跳过，最后告诉我哪些文件你没处理"——这种任务 agent 做起来就很合适。目标明确、步骤可拆、中间结果可验证、需要一定的自主判断但判断空间有限。
所以关键不是"agent 厉不厉害"，而是"你的任务适不适合 agent"。选对了场景，agent 是神器。选错了场景，agent 就是花架子。
几个框架的体感
我试了目前主流的几个 agent 框架。说说感受。
LangGraph： 最成熟的那个。核心思想是把 agent 的工作流程建模成图（graph）——节点是操作，边是条件。你可以精确控制每一步的行为和流转逻辑。适合需要精细控制的场景，但学习曲线陡峭，配置复杂。我的感觉是：它更像一个工作流引擎，而不是一个"聪明的 agent"。你需要自己定义好所有路径，agent 的"自主性"体现在它能根据条件选择走哪条路径，但路径本身是你预设的。
OpenAI Agents SDK： OpenAI 官方出的，设计思路比 LangGraph 轻量很多。你定义 agent 和 tool，agent 自己决定调用哪个 tool、怎么组合结果。适合快速原型，但对复杂场景的控制力不足。它的哲学是"给 agent 足够的自由"，但自由多了就容易跑偏。
AutoGen： 微软搞的，核心概念是"多个 agent 协作"。你定义不同角色的 agent——coder、reviewer、planner，让它们互相讨论、互相检查。这个想法很有意思，但实际用下来 token 消耗巨大，而且 agent 之间的"讨论"经常变成废话循环。两个 agent 来回说"你说得对""那我们试试"，实际上什么也没推进。
Claude Code / Codex CLI： 严格来说不是 agent 框架，而是 agent 能力的终端化体现。你在命令行里给一个目标，它自己读文件、写代码、跑测试、调 bug。实际体感是目前最好的——因为它不需要你配置框架，直接用就行。但它也有局限：单次任务可以，复杂项目级别的编排还是需要人来管。
工种变了，不是消失了
聊完框架，聊聊我真正想说的——agent 对程序员工作方式的影响。
我越来越觉得，AI Agent 跟程序员的关系不是替代，而是分工重组。以前一个人干所有事：理解需求、设计方案、写代码、做测试、写文档、部署上线。现在 agent 能替你干其中一部分，你需要做的是搞清楚哪部分该交给它。
我的经验是这么分的：
Agent 负责执行，人负责判断。 "把这个接口改成 POST""在这个文件里加上错误处理""生成 10 个测试用例覆盖这个函数"——这种有明确目标和评估标准的任务，交给 agent 做效率很高。但"这个方案合不合理""这段代码的性能瓶颈在哪""该不该做这个功能"——这种需要综合判断的事，目前还是得人来。
Agent 负责局部，人负责全局。 Agent 擅长在有限范围内解决问题。你给它一个函数、一个文件、一个模块的任务，它能处理得不错。但如果你给它一个跨模块的架构调整任务，它经常顾此失彼。全局视野和跨模块的协调，目前还是人的活。
Agent 负责已知模式，人负责未知探索。 如果你要实现的东西有成熟模式可循——标准的 CRUD、常见的设计模式、典型的架构方案——agent 做起来得心应手。但如果你要做的是一个全新的、没有先例的东西，agent 就抓瞎了。创新和探索，目前还是人的领域。
这个分工模式看起来好像没变什么——人还是做那些重要的事。但区别在于：以前那些"不那么重要但很花时间"的事（写测试、写文档、做脚手架、改格式）占了你大部分工作时间，现在这些事可以交给 agent 了。省下来的时间，你可以用在真正需要人脑的事上。
一个有意思的推论
如果上面的分工模式是对的，那可以推出一个有点反直觉的结论：
Agent 的普及会让高级程序员更值钱，而不是更便宜。
为什么？因为 agent 降低的是"执行"的成本，而不是"判断"的成本。以前一个高级程序员的价值有一部分体现在"他写代码又快又好"，这部分价值确实会被 agent 侵蚀。但他的另一部分价值——设计方案、做技术决策、协调团队——这些价值不但没被侵蚀，反而更稀缺了。
当所有人都能让 agent 帮自己写代码的时候，"会写代码"就不值钱了，"知道该写什么代码"才值钱。
这对初级程序员意味着什么？意味着光会写代码不够了，你得尽快培养判断能力和全局视野。不是说代码不重要了——代码依然是基础——而是说代码只是起点，不是终点。
我观察到的一个趋势是：现在好的技术 leader 花在写代码上的时间越来越少，花在"决定怎么写"上的时间越来越多。以前可能 70% 写代码、30% 做决策，现在变成了 30% 写代码、70% 做决策。这个比例变化，在 agent 普及之后只会加速。
还有一个值得注意的现象：agent 框架的出现让"小团队做大事"成为可能。以前一个 10 人的团队能做的事，现在 3 个人加上几个 agent 也能做。不是因为 agent 替代了 7 个人，而是因为 agent 把那 7 个人的执行效率提升了好几倍。剩下的 3 个人只需要做好协调和判断。
这意味着什么？意味着创业的成本在降低，但创业对人的要求在提高。你不需要雇很多人来执行，但你需要能做决策的人。而做决策的能力，目前 AI 还帮不上忙。
什么时候该用 Agent，什么时候不该
最后给几个实操建议。
适合用 Agent 的场景： 代码重构（改命名、拆函数、统一风格）、批量操作（给所有接口加日志、给所有表加字段）、测试生成、文档生成、数据处理脚本。这些任务目标明确、步骤清晰、结果可验证，agent 做起来效率极高。
不适合用 Agent 的场景： 需求分析、架构设计、性能优化（尤其是需要分析全局瓶颈的）、新技术选型、跨团队的技术协调。这些任务需要人类的判断力和上下文理解能力，agent 目前做不好。
可以用但要小心的场景： 新功能开发、bug 修复、代码审查。这些任务 agent 能帮上忙，但你需要全程监督，不能完全放手。agent 可以帮你生成初稿，但最终决策权必须在你手里。
说到底，agent 不是你的替代品，是你的实习生。一个非常勤奋、不知疲倦、知识面很广但经验不足的实习生。你会让实习生帮你做一些确定性高的工作，但不会让他做需要经验判断的决策。
对待 agent，就该用对待实习生的心态：给明确的指令，检查输出结果，在关键节点把关。你能教好一个实习生，就能用好一个 agent。区别只是实习生会成长，agent 目前不会——至少在同一次任务中不会。
其实还有个类比可能更贴切：agent 更像一个自动驾驶系统。在高速公路上（规则明确、场景简单），它可以完全接管。在城市复杂路况下（规则模糊、场景多变），你需要随时准备接管。在极端天气或突发状况下（系统边界之外），你必须完全自己来。
大部分开发者目前对 agent 的态度是两个极端：要么觉得它无所不能、完全放手，要么觉得它不行、完全不用。正确的态度应该是在中间——知道它的能力边界，把合适的工作交给它，同时保持自己的判断力。
我见过最好的 agent 使用方式，是一个团队 lead 做的：他给团队规定了"哪些任务可以用 agent、哪些不可以、用的时候怎么验收"。简单任务（改名、迁移、补类型）直接让 agent 做，PR review 只看 diff 不看过程。中等任务（新功能、重构）让 agent 先出一版，人在上面改。复杂任务（架构、性能）自己做，只让 agent 辅助查资料。这套规则实施之后，团队的代码产出效率提升了大约 40%，但代码质量没有下降。
行了，agent 这个话题就先聊到这。等下一波框架更新了，可能上面说的又过时了。但"分工重组"这个大方向，短期内不会变。与其焦虑 agent 会不会取代你，不如想想你的工作里哪些部分适合交给 agent，省下来的时间用在哪里。
#AIAgent #LangGraph #AutoGen #OpenAI #程序员 #分工 #开发工具 #AI编程 #ClaudeCode #Copilot #技术趋势 #软件开发 #工程实践 #代码自动化 #职业发展
Q.E.D.
