> ## Content Index > Fetch the complete content index at: https://www.hubwiz.com/blog/llms.txt > Use this file to discover other available public pages before exploring further. # 编排者，软件开发的新角色 - URL: https://www.hubwiz.com/blog/orchestrator-a-new-role-for-software-development/ - Published: 2026-08-08T14:37:33.000Z - Updated: 2026-10-13T16:13:59.000Z - Description: 一个给专家们的新职位头衔：通过指挥系统、智能体和结果来交付系统 - Author: admin - Tags: JOB MARKET, #Import 2026-10-14 14:41 每个人都在谈论开发者的消亡。我理解。那个专门写样板代码或搭 CRUD 应用脚手架的开发者已经完了——模型几秒钟就能完成这些，那个开发者不会回来了。但那些宣告编程终结的人漏掉了一些东西。一个全新的职位头衔正在软件的多个领域浮现。 架构师和开发者正在变成"编排者"——一个人指挥曾经需要整个团队才能完成的工作。这种转变的影响将远远超出软件领域，但软件工程是我亲眼目睹的地方。 编排者知道如何开发软件，但他们的工作不再是写代码——而是监督一个系统，编排工具和智能体，把各个组件拼装成一个必须能在生产环境中运行的东西。但"编排者"和"软件开发者"之间最重要的区别在于：编排者更少关注交付软件本身，而更多关注编排那些既能运行软件、又能开发软件的系统。 过去用来设计数据库模式或对象模型结构的技术专长，如今将被用来指导一组已经承担了大多数战术性、行级决策责任的子系统。2023 年的"开发者"专注于决定 React 应用如何存储状态，而 2027 年的"编排者"则专注于一份 DESIGN.md 文件——它为某个子系统设定标准，该子系统负责把分析数据与客户反馈输入融合起来，以推荐、测试并实施网站改动，作为以更自主方式运营业务的宏大方案的一部分。 ## 1、编排"委派智能"系统 如今大家都在把所有东西都叫做"智能体"，但我也想提出一个想法。编排者可以而且将会使用与我们今天都在用的某些更"智能体化"的方法相似的系统，从 Hermes、OpenClaw 到每一个开始自称"智能体"的系统。我开始觉得这个词被滥用了。退一步，脱离我们今天使用的技术，我想提出："编排者"的工作是协调那些归属于一个新类别——"委派智能"——的系统。 几十年来我们一直把所有东西叫做"人工智能"。这个词，再加上"生成式 AI"和"推理引擎"，都无法捕捉我们开始在实践中所看到的东西。一个拥有记忆、能够以一定程度的独立性开始运作的智能体化系统，展现的就是"委派智能"（delegated intelligence），而"委派"这个词承载了很多含义。它意味着这个类别中的系统将始终可以追溯到某个负有责任的运营者，或者在这个语境下，追溯到一位"编排者"。 > 向编排者转变的根本，是自动化、生产力和问责制的结合。随着组织、公司和政府开始利用委派智能来支持更自主的设计、运营和工程方式，建立问责制的需求将日益增长。如果你的业务在一组自主智能体上运行关键基础设施，那么在发生故障时，有一个问题将变得必须回答："这些委派智能是在谁的授权下运作的？" ## 2、编排者的生态：通才与专才 有编排者，也有技术专才。向通才型专长的转变标志着编排者的出现，因为专才的能力如今大多存在于模型之中。你仍然需要几个专才，但不需要为每项技术都配一个——而且即使是某些专才，也会变成专才型编排者。事情会变得复杂起来。 你将寻找那些能端到端理解整个体系的通才编排者。你可以把编排者想象成一位文艺复兴式的专家程序员——通常是那些有几十年经验、理解软件开发端到端生命周期的人。正是这些人正在变成编排者，而这正在改变 IT 部门的整体构成。我们不再是程序员了。 让我用我自己的经历来描绘这种新现实的样子。最近，我必须为一套自出版的系列有声书添加 DRM——一个[听不见的水印](https://en.wikipedia.org/wiki/Audio%5Fwatermark%5Fdetection?ref=hubwiz.com)，把订单特定数据编码进音频文件里，这样如果我在网上发现其中一个文件，就能识别出是谁买的。我不是叠加音频水印的领域专家，但我确实懂怎么写处理声音文件的代码。 ## 3、编排：从几个月到几分钟 这个特定任务以前会花我几周甚至几个月，而在不久之前，我会通过创建一个 git 仓库、打开一个 IDE 来开始这个项目。2026 年可不是这样做的。 两周前，当我编排这个系统的创建过程时，它花了 20 分钟，而这些工具给了我三个维度的高度加密水印和指纹识别——本质上就是 3 位隐写音频专家的工作成果。 好吧，我撒谎了——其实是 40 分钟。头 20 分钟我在让模型提出 5 种不同的方案，以便我选择正确的一个。但我想强调的是，我让系统生成 5 个不同的提案，然后对每个选项的长期成本和可运维性进行建模。我还给了它方向，让它考虑客户体验、为每个选项创建优缺点矩阵，并以建议作为结尾。 这一切都由一个已经跟踪内容开发数月之久的系统完成，它在跳入实现之前，利用客户知识、分析和产品设计来为它呈现给编排者的选项集提供依据。 ## 4、你的工作不是代码，而是编排 现在我工作的一部分，不仅是利用这些工具来"创造"，还要在构思、产品设计和质量工程阶段使用它们。编排者之所以存在，是因为这个人知道该问什么问题。仅仅四年前，完成这件事可能需要我花三个月和一支庞大的团队，而我在没有逐行阅读的情况下就把它交付了。 > 坦率地说，这是一个奇怪的位置，三年前的那个"我"听到我实现了某些东西却没有自己写代码，会非常不舒服。事实上，我最初对 Steve Yegge 说"他应该停止阅读自己的代码"的反应非常负面，而我至今对这个观点仍有一些保留意见，但我可以说，在我自己的实践中，我开始不读我的代码了——因为它不是我的代码。 和许多正在读这篇文章的程序员一样，我必须经历一次作为程序员的身份时刻——接受自己交付到生产环境的东西，可能没有逐行读过。那可能有十万行代码——多到读不过来——而且说实话，那不再是我的工作了。我是一名编排者，如果我试图跟上这一切，那会非常低效。 我不是 vibe-coder，也不是"公民开发者"——这个词我讨厌到想骂人，因为它根本就是个错误的词。我是一个本来就能写代码的人，但我决定把这项任务委派给一个掌握的资讯比我所能收集到的还要多的系统。而这些系统——像智能体这样的委派智能工具——虽然能在短短几分钟内实现系统，但它们仍然需要一个人类来对方向进行权衡。而且我主张，我们仍然需要一个人类在场并承担责任。 编排者懂得足够多，能理解系统为他们做了什么，也能在出问题时深入细节。他们知道如何调试，他们对什么有效、什么无效有感觉，他们对自己知道什么、不知道什么很诚实。 ## 5、编排者即完成者 这里是争议的部分。这绝对与"技术民主化"无关。有一个神话是，任何人都能拿起这些工具就写代码，这确实是真的——是的，任何人都能写代码，但不是每个人都能以可扩展、安全的方式把它交付到生产环境。 > *我的一位同事最近写道，用生成式 AI 启动项目很容易，难的是完成它们。把某样东西交付到生产环境，所需付出的努力、精力和技术专长，和过去一样多。* "任何人都能拿起生成式 AI 工具创造出技术完美的作品"——这个神话即将破灭。如果你在没有专人负责编排某个复杂技术系统的创建和运营的情况下构建了它，总有一天你得花钱雇人来为你做这件事，而那个人会向你收取很高的费用。 ## 6、编排者为意外做规划：可支持性 我刚刚谈到的那个 DRM 系统——我没有逐行读过，但在交付之前，我确保自己理解了未来支持的基线。虽然我把创建它的权力委派给了一个智能体，但我同时也确保让同一个智能体记录代码位置、架构、方法，并生成一套文档系统，以便在 AI 不可用时可以用来调试和支持它。 在部署到生产环境之前，我从头到尾读过这份"飞行员手册"吗？没有。但我知道油门指示器在哪里，如果需要我在没有自动驾驶的情况下降落这架飞机，我能做到。这是这个新角色的职责之一：为"离线"做规划，把各种意外情况想透。 关键点在于，我足够合格，能读懂 AI 为我写的那份飞行员手册，以备我需要调试它；而且如果明天 AI 消失了，我能自己重建它。对于许多通过 AI 进入编程世界的人来说，情况并非如此，而这会造成一种对工具的依赖，这种依赖需要被管理——管理方式之一就是通过持证的编排者，他们能够在不借助工具的情况下创建并支持系统，尤其是在受监管和关键领域。 ## 7、让组织适应这个新兴角色 事情变化得很快——一名编排者等于 20 或 30 名开发者，外加整队的 QA 工程师。虽然我们仍然需要产品人员和思考客户的人，但技术工作正在围绕指挥它的那个人而整合。 在你问之前——为什么不干脆叫它架构师？因为架构师从来就没用。如果你在一家设有架构师的公司工作过，他们往往是那种已经不再写代码、真要写可能也写不了、纯粹在那儿告诉别人该做什么的人。这是一个过了巅峰期的职位——如今，任何思考代码的人都应该在某种程度上写代码。 编排者不是那种整天盯着 IDE 的沉默寡言程序员；他们是理解完整端到端流程的人——不仅理解技术系统中的数据流，还理解业务如何运作并自主适应。他们有技术能力，但也专注于提供监督，他们是负责决定何种智能可以被委派的人。 **那么我们如何培养编排者？** 不是通过训练营或六周证书。这将需要一个学徒计划——数年的学徒制，就像我们培养医生和律师那样。你在一个知道该关注什么的人手下工作，通过观察他们做决定来学习。 这些员工可能造成真正的损害，他们是行走的负债。当一家公司为写代码的人购买保险时，那是一套风险。当你为效率高一百倍的专业人士投保时，他们也承担着一百倍的责任。保险费率、监管和认证要求都会上升。医生要买[医疗事故保险](https://www.ama-assn.org/practice-management/sustainability/medical-liability-malpractice-insurance?ref=hubwiz.com)，因为他们的决定影响人们的生命。 > [*专业工程师*](https://www.nspe.org/resources/licensure/what-pe?ref=hubwiz.com)*必须持有执照，因为工程影响公共安全。编排者正朝着同一个方向走去。* 如果你快进 20 或 30 年，我们现在称为程序员的人将成为编排者，他们会更像医生和律师，而不是现在这拨写代码的人。 代码将成为工作的一部分，但不再是工作的大部分。 --- 原文链接: [What's an Orchestrator — and Why Does Software Need One?](https://medium.com/@tobrien/whats-an-orchestrator-and-why-does-software-need-one-5079bd71e57e?ref=hubwiz.com) 汇智网翻译整理，转载请标明出处 > **这是「Agent / MCP」专题的一部分。**完整地图见：[Agent / MCP / 自动化完全指南](https://www.hubwiz.com/blog/agent-stack/)