AI 代理的组织结构图：绘制您的人工与 AI 劳动力

Source: Dev.to

大多数团队需要的警醒

我已经在这么做了。我的团队让 AI 代理完成真实工作，拥有明确的角色、人类所有者和绩效指标。我们早已超越“是否应该使用 AI？”的讨论。但当我和其他工程领袖交流时，大多数人仍在进行“如何有效使用 ChatGPT”的试点。他们在争论工具，而我们已经在部署工作者。如果你是这种情况，请醒醒。AI 代理已经在这里。它们不是将要到来，而是已经在工作。它们必须出现在你的组织结构图中。

我并不是在打比喻。这些并不是放在架子上等着调用的工具。它们是贯穿整个开发生命周期的真实工作系统。它们读取 Jira 任务并将其拆解为更小、可执行的子任务。它们分析代码库以获取上下文后再编写代码。它们本身就写代码。它们审查来自人类和其他代理的 Pull Request，在合并前捕获问题。它们运行测试，解释失败并修复破坏的部分。它们部署到预发布和生产环境。它们更新任务状态并添加实现说明。它们在功能发布时生成文档。它们 24/7 运行。它们有明确的职责。它们产生影响业务的输出。

如果这听起来像是一份职位描述，那是因为它确实是。

问题不在于 AI 代理是否应该出现在你的组织结构图上，而在于你为什么还没有把它们放进去。

大多数团队需要的警醒

让我描述一下我在实际推进 AI 采用的组织中看到的情况。

公司 A 在整个开发工作流中嵌入了代理。一个代理监控待办事项，拆解任务，并在工程师一天开始工作前准备实现计划。另一个代理接手任务并实际编写代码，创建准备审查的 PR。第三个代理审查每个 PR，检查安全问题、测试覆盖率和架构一致性。第四个代理负责部署，监控发布，并在错误率飙升时自动回滚。它们的工程主管把这些代理当作团队成员，因为在功能上，它们就是。它们有所有者、绩效指标和明确的职责。

公司 B 仍在让工程团队争论 Copilot 是否值得付费许可证。他们正以委员会形式进行为期三个月的试点以评估结果。开发者手动逐行审查每个 PR，通过手动检查清单进行部署，并在每个任务的第一小时里仅仅理解需要构建的内容。

这两者之间的差距不是技术，而是思维方式。

• 公司 A 问：“我们如何把 AI 融入工作方式？”
• 公司 B 问：“我们应该使用 AI 吗？”

等公司 B 还在提问时，公司 A 已经部署了它们的第四个代理。

这就是警醒：AI 代理已经在这里。它们在工作。它们在产出。代理式 AI 的采用曲线比我们以往见过的任何东西都快。两年内，大约三分之一的企业已经在生产环境中部署了代理。而真正使用它们的组织？大多数已经把代理当作同事，而不是工具。如果你仍把它当作“采用新工具”，那么你已经落后于那些把它视为“构建混合劳动力”的团队。

为什么代理应该出现在组织结构图上

我知道你在想什么。“把软件放进组织结构图听起来很荒唐。”但请听我说。

组织结构图的存在是为了清晰。 它们回答：谁负责什么？谁对什么负责？谁向谁汇报？如果一个 AI 代理在做有意义的工作，这些问题同样适用于它。

当你不把 AI 代理纳入组织结构时，就会产生“隐形工人”。工作在进行，但没人确切知道是谁在做，出错时也没有人负责。这可不是小问题。这正是导致无人可追溯的事故、无人察觉的漂移以及隐形技术债务的根源。

把 AI 代理放进组织结构图真正解决的事

• 问责制。 每个代理都有一个人类所有者。当开发代理写出的代码在生产环境崩溃时，有人负责改进其防护措施。当代码审查代理漏掉安全问题时，有人调优其规则。当部署代理导致发布失败时，有人负责事后分析。当任务分析代理持续高估复杂度时，有人调整其模型。不再有“是 AI 的错”这种借口。

• 可视性。 团队可以看到到底是谁在做工作。每个人都知道任务分析代理在冲刺计划前拆解并估算新问题。开发代理接手已批准的任务并创建 PR。代码审查代理在技术负责人看到之前检查每个 PR。部署代理自动处理预发布，但会标记生产部署以供人工批准。没有神秘工人。

• 规划。 当你了解完整的劳动力（人类和 AI）时，就能正确规划容量。你知道自己拥有的、能做的以及缺口在哪里。于是可以真正决定是招聘人类还是部署更多代理。

• 协作。 工作流变得明确。“新任务先由任务分析代理分析，拆分为子任务并估算复杂度。开发代理接手任务并编写代码。代码审查代理检查每个 PR。若通过自动检查，技术负责人进行最终审查。部署代理处理预发布，运行集成测试，并通知团队。生产部署需要人工批准。”每个人都清楚人类与代理之间的交接点。

实际操作示例

错误做法： 你给开发者提供 Copilot 并宣称完成。有人大量使用，有人忽视它。没有人知道哪些代码是 AI 辅助的。PR 被合并时，没人了解 AI 建议是好是坏。当 bug 滑过去时，根本追溯不到是否是 AI 生成的代码导致的。团队拥有 AI，却没有围绕它的结构。

正确做法： 你部署的代理在组织结构中拥有明确位置。

• 你的开发代理向技术负责人汇报。它从待办事项中挑选任务，分析代码库上下文，编写代码、添加测试并创建 PR。
• 技术负责人审查其输出，若方法错误提供反馈，若正确则批准。
• 你的代码审查代理同样向技术负责人汇报。它检查每个 PR 的安全漏洞、测试覆盖缺口和架构模式违规。它在 PR 上发表评论、请求修改并在符合标准时批准。
• 人类负责判断：这是不是正确的方案？这是否真正解决了问题？

同样的模式贯穿整个开发生命周期。你的任务分析代理向负责待办事项梳理的人汇报。你的部署代理向负责发布管理的人汇报。你的文档代理向负责开发者体验的人汇报。每个代理都有明确的范围、所有者和指标。

这不是理论。我团队就是这样运作的，我认识的每个高绩效团队也已经完成了这种转变。他们不把 AI 当作工具使用，而是把它当作需要管理的能力。

实际执行团队的最佳实践

我领导的团队就是这样运作的，我也与全球的工程领袖保持联系，大家的做法大同小异。以下模式效果更佳。

为每个代理指定人类所有者

这点不可妥协。每个 AI 代理都必须有一个对其输出负责的人类。不是“出问题时负责”，而是“全程负责”，毫无例外。

该负责人应：

• 定期审查代理的输出（不仅在出现问题时）。
• 定义并监控与业务目标对齐的绩效指标。
• 当质量出现漂移时，调整代理的参数、提示或模型。
• 确保代理遵守安全、隐私和治理政策。
• 成为涉及该代理工作的事件的升级点。