首席技术官的视角：与首席执行官探讨代理式人工智能

Arvind Mathur：
感谢您收听本期高管洞见。我是 AWS 的企业战略分析师 Arvind Mathur。很高兴今天能与我的同事 Matthias Patzak 展开对话。Matthias 近期在领英上发布了一篇博客，引发了广泛讨论。今天我们将围绕这篇文章的内容，探讨它为何能引发诸多热议。Matthias，欢迎光临本节目。  

Matthias Patzak：
非常感谢。确实，这篇博客带来了很多讨论，我也收到了很多评论。

Arvind Mathur：
最重要的是，这类发人深省的内容所引发的对话非常有价值。

我想这正是它能吸引大量关注的原因，因为作为技术领导者，我们都曾遇到过这样的情况：明明知道必须关注某一新技术趋势，却没能投入足够精力。等到首席执行官或其他高管主动询问时，自己总会陷入被动。我想这就是让很多人产生共鸣并带来高互动量的原因。 

Matthias Patzak：
是的，确实如此。我想，领英上这篇文章之所以能获得大量浏览，原因就在于首席执行官不得不问首席技术官，“嘿，这个代理式人工智能到底是什么”这一场景。 直到现在，我仍在很多组织中看到类似情况：首席技术官、首席信息官、工程副总裁们终日被日常业务缠身，要维持现有系统运转，要在当前各项优先任务间分配资源，根本没有精力（无论是脑力、人力还是预算）去尝试新技术。 

Arvind Mathur：
完全同意。而且我认为，当下首席技术官和技术领导者比以往任何时候都更需要在这方面投入时间，因为情况变化太快了。更重要的是，现在很多技术能力已高度“消费化”，业务领导者对这些技术的认知也远比过去深入，所以当他们提出相关问题时，你绝不能陷入被动。就像你之前所建议的，必须分出部分精力来关注这些新技术，甚至主动向业务领导者介绍它们，对吧？

Matthias Patzak：
是的。

Arvind Mathur：
那我们不妨来聊聊你的具体建议，该如何实际解决这个问题。我知道这部分内容也引发了不少讨论。我很欣赏你提出的部分建议，它们极具启发性，而且我认为，我们不妨深入探讨其中一些内容，进行更细致的分析。

Matthias Patzak：
其实我提出的第一步建议是，把技术讨论转化为业务对话。因为直到现在，大多数首席技术官和首席信息官仍然只关注新技术本身。他们想了解技术的防护机制、成本，却没有采用我们在亚马逊常说的从客户需求出发逆向推导的思路。他们没有深入到实际环境中去观察客户和用户，没有真正观察客户的需求与痛点，他们没有真正了解客户需求和客户问题，作为 IT 专家，他们无法与业务同行进行业务对话。这就是我在领英文章中提出的第一点：要将讨论转化为业务对话。

Arvind Mathur：
完全同意。我认为也必须是一次业务对话，因为这是创造业务价值的机会，而不只是对后端系统的优化。我认为你文章中引发讨论的一点，是关于“寻找能带来 10 倍价值的方案，而非仅提升 10% 的小改进”。告诉你，我特别欣赏这个观点，因为它很有启发性。尤其是有了代理式人工智能，现在比过去很多技术都更容易找到这类 10 倍价值的机会。但现实是，我们日常工作中，可能 90% 的精力都花在只能带来 10% 改进的项目上，只有 5% 到 10% 的精力投入到能创造 10 倍价值的方案上。你为什么会强调要聚焦这类 10 倍价值的方案呢？

Matthias Patzak：
总的来说，我认为组织中这种渐进式的迭代改进才是真正造就成功组织的因素，因为这样才能成为一个持续学习的组织。如果你了解自身的业务和技术，每天、每周都能改进 1%、2%、3%，甚至 10%，这就很有意义。但是，我发现在关于生成式人工智能、通用人工智能，以及现在的代理式人工智能的讨论中，很多组织只想着如何提升内部效率，却没有思考如何调整业务模式。在我看来，未来会出现这样的趋势，就像 10 到 20 年前数字原生公司出现，然后又出现移动优先公司一样，未来也会出现生成式人工智能原生公司和代理式人工智能组织。那么，如果只是在当前业务模式下工作，很可能会失败。

Arvind Mathur：
没错，我同意。越早开始寻找 10 倍价值的机会，情况就越有利。有一点需要注意：在你描述的这种场景下，也就是当你本就处于被动地位，而业务领导主动找你时，他们往往也会带着自己的想法来。根据我的观察，这也正是此类场景下的沟通关键，你得先判断当下的局面。有时候，对于首席执行官可能提出的想法，你需要快速行动并展示成果。比如他们可能会说：“关于代理式人工智能，我一直很担心这个问题。它能解决吗？” 这时候快速找到并提供方法通常非常有用。同时，在建立起信心和信誉后，再进一步沟通：“其实这不仅是一个小改进的机会，借助这项技术我们还能做更多事。” 我知道关于这个话题，评论区也有很多精彩讨论，但这个思路确实很棒。我们接着聊聊第二点建议吧。

Matthias Patzak：
第二条建议其实是对一个传统观点的重新表述，我把它总结为组建转型小组，而非技术团队。实际上传递的信息是，不应该局限于传统的 IT 孤岛工作模式中。当然，首先需要理解新技术的核心概念，但是，如果真的想交付原型，了解商业机会，就需要让销售负责人、运营人员、财务人员、法务人员也参与进来。而且他们不只是“监督者”，而是要真正加入跨职能的转型讨论。因为这不是一个单纯的技术项目，而且是对业务的重塑。

Arvind Mathur：
而且，我认为对话中对此已经达成了完全一致和共识。我个人也非常认同，尤其是对于代理式人工智能这类技术。如果想聚焦能带来 10 倍价值的方案，那这类方案绝不是内部技术改进方案。它们本质上是重新构想的机会，重新构想客户体验产品与服务的方式、产品与服务所能实现的价值，诸如此类。这需要广泛的转型。

Matthias Patzak：
你在与客户的对话中感知和观察到什么？ 你看到组织真的在这些转型小组中以跨职能团队的形式工作，还是看到 IT 团队各自为政？

Arvind Mathur：
情况各不相同。有些成熟度较高的组织已经明白这个道理，他们有过“只把项目当技术任务来做，但最终失败”的经历。但仍有大量组织仍在使用对待技术项目的方式来处理这类工作。这也正是我们在与首席技术官或业务高管对话时所扮演的角色，我们要帮助他们了解，这是一个需要打破孤岛、整合多职能力量的机遇。我个人也从自身经历中获得了深刻的体会。之前在一家保险公司工作时，我们试图转变核保、理赔等流程。这些流程虽然归运营组织负责，但转型绝不能只靠运营团队，销售、产品、风控、客户体验等部门都必须参与。要进行任何改变，这些部门都必须参与进来。当时，我们尝试将理赔时间从 3 到 4 周缩短到 1 小时以内，这种巨大的变革，绝不可能只靠优化内部运营流程实现。所以我完全同意你的观点。

Arvind Mathur：
好的，那我们来聊聊第三步。

Matthias Patzak：
我提出的第三步是，挑选 2 到 3 个相关的应用场景，然后快速行动。核心在于“快速行动”，这些试点项目要并行开展，而非按顺序推进，同时要在有防护机制的前提下追求速度。进行这类试验时，防护机制至关重要，这比追求完美规划更有效。这是我根据实际观察得出的结论，我们团队的同事 Jake Burns 常说：“不要等准备好再开始，要在开始的过程中做好准备。” 我非常认同这句话，尤其是在代理式人工智能方面，更是如此。快速行动和并行开展试点项目还有一层考虑，因为这是一项新技术，对应的应用场景也是全新的。而且，由于这是试验，因此需要做好准备，70% 的试验会失败。

如果按顺序进行试点，可能第一个、第二个、第三个都失败了，直到第四个迭代、第四次试验才能真正成功。所以我才建议，作为首席技术官，得有足够的精力，无论是脑力，还是预算、人力层面，这样才能让试点项目并行开展。这个话题之前也引发了很多讨论，因为有些组织似乎既没有这样的魄力，也没有足够的资源来这么做。

Arvind Mathur：
你之前问过我和客户交流的情况，这可能是他们面临的首要挑战。原因在于，大多数首席技术官在这种情况下，没有能力，因此也缺乏信心去并行推进多个大型项目。他们会觉得按部就班更稳妥，我以前面对新技术没信心时也会这样，更愿意先小范围尝试，而且往往不会声张，先通过这种方式积累经验、建立信心，之后再加快推进速度。

而且我认为这是非常重要的一点，希望在与首席执行官对话之前已经这样做了。因为如果完成了这些小规模试验，就有信心去寻找那些能带来 10 倍价值的方案，进而推动它们并行落地。我认为这篇文章的核心观点，也是我特别认同的一点，就是不该等首席执行官发起这类对话，而是应该先做完试验，并带着想法去找他们，然后就可以满怀信心地推动这项工作。

Matthias Patzak：
没错，这其实必须成为运营模式的一部分，也必须融入企业文化。

Arvind Mathur：
评论区有人提出一个问题：“现在新事物层出不穷，有代理式人工智能，机器人技术在向不同的方向发展，还有核心人工智能、数据，以及提升数据与分析能力的新方法等等。要如何关注所有动态，并开展足够的试验，才能主动向业务领导汇报进展？ 你见过哪些最佳实践？”

Matthias Patzak：
事实上，不可能尝试、试验并深入了解每一个趋势。正因为如此，组织内部也需要建立一套创新雷达或技术雷达机制。有一位思想领袖 Pascal Finette 他写过一本名为《Disrupt Disruption》（《颠覆“颠覆”》）的书。在书中，他探讨了如何识别各类信号，包括技术、市场、客户层面的变化信号。接下来的问题是：多久遇到一次这些信号？ 如果某类技术领域的信号频繁出现，那就需要立刻行动，针对这类技术开展试验。正因为如此，还需要不同的工作方式来开展试验。

比如，对于某些信号，可能只需要一名开发人员、设计师或产品经理，在周五下午结合真实客户需求做个原型试验即可。而对于另一些试验，则需要为团队预留两周的专属时间，并有时间限制。也就是说，团队要在这两周内取得成绩，之后不会再投入更多资金、人力或时间。但是，需要能够识别信号，并根据信号采取行动。或许更重要的一点是，要学会对某些领域的信号说“不”。所以，能否做好优先级排序是关键所在。

Arvind Mathur：
没错，而且你之前提到的一点也至关重要，我自己不仅践行过，也常建议他人重视，那就是培养“好奇、试验”的文化，这种文化最终能催生出创新。从我个人的实践经验来看，如果在团队和组织内部建立了这样的文化，即便没有专门制定相关战略或行动计划，团队成员也会主动开展试验，密切关注行业动态，留意技术雷达上显示的新趋势。我经历过最有价值的情况是，有个团队主动来找我说：“Arvind，我们一直在研究这个领域，觉得它很有潜力。” 这样我就能带着这个发现去找业务团队，问他们：“我们发现了这个机会，有没有办法采取行动？” 所以，如果已经有了这样的文化，那就太棒了。如果还没有，从现在就开始构建吧。因为在当今世界，如果团队不会主动去关注趋势、开展试验，那么当机遇真正来临时，就很难抓住它。

Matthias Patzak：
没错，我完全同意。要做到这一点，关键在于公开试验的成功与失败，否则到最后，产品经理或业务同事肯定会有意见。毕竟团队会抽出一部分精力去研究新技术，这就意味着投入到“交付业务价值或功能开发”的精力会减少。所以，一定要表彰成功的试验。即使试验失败了，从试验本身的角度来说也是一种收获，同样需要在组织内部赞扬这种经历。这样可以营造一种文化，即组织鼓励抽出精力去尝试新技术、验证新业务想法。

Arvind Mathur：
非常好。让我们进入第四步。

Matthias Patzak：
是的，第四步。从我的角度来看，我发现大家对这一点的评论特别有意思。这条建议是，在试点阶段就要为规模化应用做好准备。不要只对花哨的演示进行原型设计，而是要从一开始就构建生产就绪型解决方案，确保它能承载企业级的业务量。在我看来，代理有不同类型，比如面向知识型员工的代理，例如，客服人员打算在其桌面上使用代理来帮助自动执行某些工作流程。但作为前首席技术官，我觉得具备自主决策能力的微服务型代理更有意思。不过，要将这类代理融入架构和应用程序，难度并不小。

因此，需要有事件驱动的架构。需要建立适当的可观测性体系，而且至少在原型设计开始时，就需要能够让人工外围监督、人工深度融入，有时则是在系统稳定后撤出人工干预。另外，只有让代理进入生产环境，才能真正了解它的能力，不一定让它承担 100% 的流量，刚开始可以只分配 1% 的用户、1% 的流量，这样在验证 10 倍价值方案的同时，能最大限度控制风险影响范围。但很多人很难理解并落实这一点，究其原因，可能还是缺乏包容失败的文化。

Arvind Mathur：
而且我认为，你提到的这一点其实和之前的观点也能很好地衔接，即使在试验过程中，也是分阶段的。可以先开展一些与企业完全无关的试验。如果其中某些试验开始显现潜力，再着手在组织内部的 IT 部门先进行试点。就像你刚才提到的，我特别认同的观点，当已经具有通过服务和 API 支撑的业务流程，只需在内部部署“大脑”，就能积累经验，逐步熟悉如何构建可投入生产的代理式功能。这样一来，当与业务方探讨跨部门的 10 倍价值机遇时，就有信心在生产环境中并行推进多个方案。这个观点非常棒。这是从试验到创新的过程中的一步，首先从组织内部的技术层面开始。

当然，我确实理解有人对此发表的评论，很多人还是觉得这样做不踏实。他们认为，像你所说的那样，尽早开展试验、控制风险影响范围，这很重要。而我们真正想强调的是，这些准备工作必须在进行业务对话之前完成。只要提前做好了这些小范围、低风险的试点、项目和试验，那么当业务机遇出现时，就能快速行动。那时，已经不再处于试验阶段，希望此时已经度过了“70% 的试验可能失败”的阶段，能够提供更稳定的能力。

Matthias Patzak：
是的，我完全同意。这就是为什么人们需要尽早亲身体验新技术的原因。我的建议是，可以联合合作伙伴，比如 AWS 客户支持团队，让他们指导你们如何操作这些新技术。

Arvind Mathur：
好的，我们来谈谈第五步。

Matthias Patzak：
是的，第五步。按理说这一点是显而易见的，但仍有讨论空间。第五步是：要衡量业务影响，而非技术指标。也就是说，要跟踪营收增长、成本降低、周期缩短、转化率变化这类指标，而不是模型准确率或用户使用率。当然，需要关注用户使用率这类前置指标。需要了解一些质量指标，但引入新技术的目的绝不能是“单纯为了采用新技术”，而是要让业务流程效率提升 10%，或是打造出能带来 10 倍价值的应用场景。正因如此，每一个投入生产的解决方案，都必须结合真实用户反馈来评估，并且要衡量其实际产生的业务影响。要做的不是在功能列表上打勾，而是能明确说出：“借助这款代理式人工智能，我们成功将网站跳出率降低了 X%。”

Arvind Mathur：
而且我认为在这一点上已经达成了普遍共识。我也想简短地分享一下自己在这方面的亲身经历，就拿之前提到的理赔流程提速项目来说吧。最开始推进这个项目时，我们犯了一个错，那就是团队内部的衡量标准不统一。运营团队有一套运营衡量标准，技术团队有另一套衡量功能交付的运营衡量标准，销售团队又有自己的衡量标准。正因为这样，项目始终达不到 10 倍价值的目标。直到所有人都对齐了同一个目标，即将理赔时间从 3 周缩短到 5 分钟，情况才有所改变。这个共同目标不仅让大家方向一致，更激发了创造力，大家开始主动找出阻碍实现 10 倍价值提升的问题，并通过跨部门协作提出了真正有创造力的解决方案。所以说，这不仅仅是衡量标准的问题，更是让团队对齐目标、聚焦真正重大障碍的有效方式，能帮助我们突破瓶颈、实现 10 倍价值提升。

Matthias Patzak：
是的，你说得对。目标对齐这一点确实非常重要。

Arvind Mathur：
关于这个的对话非常精彩。希望之后还能和大家继续交流，收集更多意见。不过，我从这次对话中收获的最重要的一点，也是我想推荐给所有人的，就是“主动关注趋势”。当前行业变化很快，必须提前了解技术能实现什么，然后带着这些思路去和业务领导沟通。所以基于这次讨论，我的建议是：现在就登录 AWS 账户，与客户支持团队沟通，弄清楚该如何使用这些工具并立即开始构建。

Matthias Patzak：
是的，完全同意。应该使用的工具，或者说亚马逊服务，就是 Amazon Bedrock Agent Core。我们围绕代理提供各种不同的服务，但将代理融入架构的核心是 Amazon Bedrock Agent Core。真心建议组织尽快上手使用这项服务。

Arvind Mathur：
太棒了。开始构建吧。

Matthias Patzak：
开始构建吧。

立即收听

立即收听

立即收听