最近看到一个很有意思的现象：

大家热衷于给 Agent 安排“同事”、设立“领导”、组建“协作群”，然后让它们开会、分工、汇报、评审，几乎原样复刻人类公司的组织结构。

如果继续发展下去，下一步可能就是给 Agent 做绩效考核和晋升答辩了。

这件事多少有点魔幻。

复制组织结构，不等于重构生产力

很多人可能还没有想清楚目标是什么，也没有识别研发过程中真正需要解决的问题，就先接受了一个假设：

只要让 Agent 像人一样组织、像人一样协作、像人一样开发，就能逐渐替代人类研发团队。

但复制人类的组织结构，并不等于重构生产力。

人类之所以需要团队、管理者、会议、汇报和复杂的协作流程，很大程度上是因为人的注意力有限、信息分散、能力不同，还存在沟通成本、利益关系和组织规模带来的管理问题。

这些机制本来就是人类在自身限制下形成的解决方案，并不是什么天然正确、适用于一切智能体的最优生产方式。

如果 Agent 最终也需要开会、层层汇报、跨团队对齐，甚至依靠一个“领导 Agent”来汇总信息，我们可能并没有创造一种新的生产方式，只是把原有组织里最繁琐的部分数字化地重演了一遍。

多 Agent 的分工应该来自问题

多 Agent 当然有价值。

当一个复杂任务确实可以拆成边界清楚、能够并行执行、结果可以独立验证的子任务时，让不同 Agent 分工协作是合理的。

但这种分工应该来自问题本身，而不是来自对人类组织形式的模仿。

重点不在于“给 Agent 安排什么职位”，而在于：

  • 这个任务为什么需要多个 Agent？
  • 单 Agent 的瓶颈到底是什么？
  • 拆分后减少了什么成本？
  • 不同任务之间如何传递可靠的状态？
  • 最终结果能不能验证，失败后能不能定位和回滚？

如果回答不了这些问题，那么所谓的“Agent 团队”，很可能只是看起来很热闹。

先替换重复动作

现阶段，Agent 在研发环节中真正应该解决的，不是急着替代整个研发团队，而是先替换掉那些持续消耗人力、又没有多少创造价值的重复动作。

比如：

  • 理解代码结构、查找调用关系
  • 生成样板代码、补齐测试、处理依赖升级
  • 排查常见 CI 问题、整理变更影响
  • 同步文档、执行发布检查、汇总监控信息

这些工作很重要，但不应该长期占用工程师大量的时间和注意力。

Agent 最现实的价值，是把人从这些机械性的环节里释放出来，让人有更多精力去理解用户、定义问题、设计业务、权衡方案，以及创造过去不存在的东西。

AI 友好的基础设施才是前提

而且，即使只是实现这一阶段的目标，企业也不能简单地接入几个 Agent，就宣布完成了 AI 化。

Agent 能不能稳定工作，最终取决于企业有没有建设出一套 AI 友好的基础设施：

  • 代码架构是否清晰，开发范式是否统一
  • 业务规则是否显式，历史废弃逻辑是否得到清理
  • 文档和代码是否一致
  • 配置平台、数据库、发布系统和监控系统是否有稳定接口
  • 权限是否能够被精细控制
  • 所有操作是否可审计、可验证、可回滚

如果这些基础条件不存在，Agent 面对的就是一个充满隐性知识、历史包袱和人为约定的环境。

它不知道哪段代码仍然有效，不知道哪个系统才是事实来源，也不知道某个看似普通的字段背后藏着什么业务承诺。

这种情况下，增加更多 Agent 不一定能解决问题，反而可能让错误传播得更快。

所以，在企业没有建立 AI 友好的基建环境之前，想让 Agent 完全替代人，本身就不现实。

人仍然是创造的主体

即使未来模型能力和基础设施都足够成熟，我也不认为复杂业务企业会彻底走向“无人化”或者“完全 Agent 化”。

因为复杂业务不是一道目标明确、边界稳定、答案唯一的数学题。

用户需求会变，市场会变，组织目标会变，价值判断也会变。很多时候，真正困难的并不是把一个已经定义好的方案实现出来，而是决定要解决什么问题、为什么解决、愿意承担什么代价，以及出现后果时由谁负责。

这些事情不是执行问题，而是创造、选择和责任的问题。

未来 Agent 可以承担越来越多的分析、实现和执行工作，研发流程的自动化比例也会越来越高。但这并不意味着人的价值会被压缩到只剩下给 Agent 下命令。

恰恰相反，当重复劳动逐渐被自动化以后，人更需要回到创造的主体位置。

人负责提出问题、确定方向、做出取舍、赋予意义并承担结果；Agent 负责扩展人的能力，加速人的判断，把人的想法更高效地变成现实。

真正值得追求的，不是复制一家公司，再把里面的员工全部换成 Agent，而是重新设计生产方式：

把机器擅长的工作尽可能交给机器，把人的时间还给创造。

Agent 可以成为越来越强大的生产力，但不应该被误认为生产的主体。

本文首发于 X：查看原文。