从 Copilot 到 通用 Agent ： 阿里在 AI Coding 上的应用和挑战

智能研发是快速发展又充满挑战的领域，除了卷上天的代码补全，基于代码的普通会话等场景外，还有基于大模型的 CodeReview，单测生成等能力陆续被开发出来并投入使用，也有部分团队开始探索端到端的生成代码，不过，随着大家在产品上越多的探索，人们对它解决复杂问题越来越缺乏信心了，问题究竟出在哪儿呢？是模型能力的问题还是发展阶段的问题？在智能化发展的现阶段我们应该做些什么呢？在 InfoQ 举办的 QCon 全球软件开发大会 上，阿里巴巴代码平台负责人向邦宇分享了“从 0 到 1，从 1 到 10：阿里在智能研发中的大模型应用与挑战”，他结合在阿里内部的探索经验介绍大模型在各个发展阶段遇到的问题和解决思路。

内容亮点

• 阿里内部的智能化产品是如何数据驱动和业务驱动智能化产品发展的，有哪些可借鉴的经验

• 了解当前大模型解决复杂问题上到底遇到了什么问题

• 了解内部智能化产品和工具存在的意义是什么，相比起外部第三方产品有哪些优势

预告：将于 10 月 23 - 25 召开的 QCon 上海站设计了「Vibe Coding」专题，想要深入了解从应用到产品到工程和算法，基于 AI 实现 Vibe Coding 效率倍增的实践案例，对这一领域最前沿的发展能有一个快速完整的理解，并在自己的业务场景中实现的同学不要错过。

以下是演讲实录（经 InfoQ 进行不改变原意的编辑整理）。

四个月之前，QCon 大会会务组邀请我来做分享，当时希望讲述我们在内部研发工具的发展历程。然而，在过去的四个月里，我们经历了诸多变化，包括外部产品的更新，还有 Agent 理论以及模型技术的进步。因此，我们现在正将大量精力投入到 Agent 方向的拓展上。最近，我一直在修改 PPT，希望能够将我们近期的工作进展、在 Agent 方面的思考以及取得的成果与大家分享。

阿里内部在 AI Coding 领域做了哪些探索

阿里巴巴在智能研发工具领域的探索起步较早，大约在 2023 年 3 月就开始启动，至今已经过去了两年多的时间。探索主要集中在以下几个方面：首先，在编程场景方面，我们进行了多方面的尝试，包括代码补全和代码会话功能。此外，我们还涉足了 Prompt 市场，希望通过这种方式让用户能够更便捷地结合大模型的能力与集成开发环境（IDE）进行开发。

其次，在代码审查（code review）方面，我们是较早投入的团队之一。目前，我们已经取得了一些成果，例如通过大模型对代码进行总结，帮助用户发现代码中的问题，并且利用 AI 技术直接辅助用户修改代码。

第三，由于工具是面向内部研发的，因此我们能够与阿里巴巴内部的多个业务以及垂直业务进行深度整合。为此，我们开发了一个 extension 功能，以更好地支持这种整合。

第四，我们在 Agent 领域也进行了较早的投入。我们在专用 Agent 和通用 Agent 上都进行了探索，这些 Agent 被应用于代码补全功能，例如在内部 Copilot 插件上，我们提供了两种补全方式：一种是传统的代码补全，另一种是多行补全，类似于 Cursor 这样的多行编辑能力。这是我们在代码补全方面的拓展，也是我们与垂直业务整合的一个应用场景。

在 Prompt 市场方面，我们最初发布的功能较少，主要是希望通过快捷指令功能，让用户能够快速使用大模型的能力，并与 IDE 进行结合。此外，我们还发现业务中存在许多自有工具、业务产品知识以及大模型的能力。因此，我们希望通过让用户能够自行编排流程或调用工具，来实现一些垂直场景的整合，这就是我们所说的 extensions 功能。

我们在 code review 场景中进行了大量探索，这已经成为我们内部广泛应用 AI 的一个重要领域。首先，我们开发了代码扫描功能，解决了当前大多数外部产品在代码审查时的一个痛点问题。目前，大多数外部产品在进行代码审查时，只能提供一个大致的总结，指出用户提交的代码中存在哪些问题，但无法精确到具体行。而我们通过大模型技术，能够直接定位到有问题的代码行，并且为用户提供了一个采纳按钮。然而，过去我们虽然能够指出具体哪一行有问题，但用户往往不愿意采纳建议，因为采纳后他们需要将代码拉取到本地，修改后再上传，整个过程较为繁琐。因此，我们进一步开发了一个“建议”功能，直接为用户提供一键修改的建议，用户可以直接采纳这些建议，从而简化了整个流程。这个功能目前在我们公司非常受欢迎。

我们还开发了代码总结功能。在过去，我们集团内部的许多开发者并没有养成对代码进行总结的习惯。然而，我们希望通过实施 AI 应用，积累大量代码与自然语言关联的数据，以便未来用于垂直业务的生成。因此，我们利用 AI 技术自动为用户生成代码总结，这些数据未来可以用于支持垂直业务的发展。

我们在内部产品的指标方面，目前的日活数量大约为 12,000 人，集团内部的渗透率大概在 65% 左右。在代码补全方面，整体采纳率约为 28%。由于阿里巴巴内部广泛使用 Java，因此在 IntelliJ IDEA 上的代码补全采纳率更高，大约为 33%。在 Code Review 方面，目前大约 20% 的代码审查问题是由 AI 生成的。

在过程中遇到了哪些挑战

尽管在阿里巴巴内部有大量用户使用我们的产品，并且我们在渗透率以及与现有平台的集成方面都做了很多工作，但另一方面，我们内部存在许多 DevOps 平台，包括代码平台、需求管理平台、发布平台和监控平台等。从理论上讲，我们应该能够与外部产品形成差异化，并开展许多垂直领域的探索。然而在过去一段时间里，虽然一线研发人员觉得工具在提升效率方面表现不错，但对于一些非一线研发人员，他们可能认为效率提升还不够。非一线可能希望从需求能够直接转换成代码，或者需求能够直接上线，这才是他们眼中最高的效率提升。因此，我们尝试了许多方法，试图从端到端的角度去解决这个问题，但效果仍然不太令人满意。

事实上，我们公司内部有大量可以整合的数据。代码平台不仅记录了每个用户、每个开发者所编写的代码背景，还涵盖了他们的需求、修改了哪些文件、文件是如何修改的，以及具体的改动点等信息。我们还会帮助开发者总结这些内容，并将其与需求和缺陷相关联。此外，我们能够通过代码仓库追踪仓库的演化过程，包括需求的变更原因、代码的修改原因等。从理论上讲，这些数据构成了一个非常有价值的仓库演化历史、代码演化历史以及变更事件和运维监控事件的集合，它们本应被充分利用。

我们希望将用户的接口、业务知识、文档、代码库以及专家经验整合起来，同时结合大模型的能力，如分类等功能，并为用户提供我们产品的 Copilot 入口和知识搜索能力，从而生成一个扩展。然而，我们发现即使是场景非常明确的情况下，也很难实现完全自动化。在阿里巴巴内部，经过多年的发展，我们积累了大量的插件化代码，可以通过学习原始代码库来生成插件代码。但即便如此，对于这些高度垂直化的需求，我们也发现很难直接生成满足用户期望的代码。原因主要有以下几点：

• 工具理解能力有限：工具很难完全理解用户的真实需求。即使是面对面沟通，人们也很难完全清晰地表达需求，因此工具在理解边界条件和约束条件时往往存在不足，难以准确把握用户意图。

• 用户需求描述不清晰：用户通常不擅长清晰地描述需求。他们可能随意描述一个需求并尝试使用工具，但如果 AI 生成的结果与预期有偏差，用户往往会放弃使用。

• 领域知识整合困难：领域知识往往难以有效整合和理解。例如，开发者在提出需求时，代码中对同一概念的命名可能不一致（如商品可能被称为“item”或“product”），这使得工具难以将用户大脑中的知识转化为模型可以学习的内容。

• 用户使用成本高：我们为用户生成的代码通常只能达到 85% 甚至 90% 的完成度，用户仍需在本地修改代码并进行测试。这导致用户使用成本较高，进而影响留存率。

大模型目前仍存在一些缺陷。首先，模型的可靠性不足，尤其是在处理复杂问题时，需要大量上下文信息。我们可能需要通过 Embedding 技术搜索大量数据，然后让大模型直接生成结果，但在这个过程中，大模型的上下文窗口往往不够大。其次，即使提供了很大的上下文窗口，随着输入内容的增加，模型抓取关键信息的能力会变弱。此外，大模型还缺乏逐步解决问题的能力。虽然推理模型可以通过扩展 tokens 来解决推理问题，但目前推理模型仍存在速度慢或 tokens 过多的问题。

在内部平台方面，我们发现平台间的信息整合并没有做好。公司内部有多个平台，如需求管理平台、代码平台、发布平台和测试平台等，这些平台在过去通常是分开部署的，通过 API 进行整合。但在大模型时代，由于数据不连通，很难在答疑场景中获取用户的完整上下文信息，导致平台间信息整合困难。

此外，经验和知识的利用也存在问题。公司内部有大量的数据和文档，但这些文档质量参差不齐，容易过时，且缺乏有效的维护策略。文档中大量的图片信息没有被很好地解析，过去我们在文档中习惯插入大量图片，而文字信息反而较少。在处理 Embedding 时，我们往往会忽略这些图片和视频，因为缺乏有效的多模态模型来理解它们。这导致我们在处理文档时，不仅文档质量差，还丢失了很多重要的信息。

因为历史原因，用户的提交历史、提交信息以及代码审查描述等都没有被规范化，导致我们在使用这些数据时，研发信息难以串联，挖掘成本极高。我们尝试通过激励措施（如咖啡券）鼓励团队成员编写文档和知识，但发现这种方法不可持续，一旦系统更新，信息又会过时。

在工程上下文方面，IDE 可以很好地解决工程上下文问题，例如在查看代码时，可以方便地跳转到函数或变量的定义，了解类的作用等。但一旦脱离 IDE，解决工程上下文问题的成本就会变得非常高。在代码审查场景中，虽然代码审查能够发现很多问题，但这些问题往往局限于代码本身，如错别字、拼写错误或代码风格问题。对于语法之外的问题，如业务逻辑或团队规范问题，目前仍很难通过自动化工具解决，只能依赖人工审查。

技术，产品和理论都在进步，带来新的机会

在过去的一年里，我们进行了大量的探索，包括与用户知识库的整合以及与用户工具的融合，并取得了一些进展，但总体来说，结果并没有那么令人满意。不过，令人欣喜的是，在过去半年中，我们观察到外部出现了大量产品的更新、技术的进步以及理论的发展，这些都为我们内部产品带来了新的机遇，也促使我们从 Copilot 向 Agent 方向转变。接下来，我将介绍我们为何会有这样的转变，以及我们观察到的一些现象。

首先，我们看到产品本身在不断进步。 例如，像 Cursor、Windsurf 等工具，都为我们提供了许多新的思路。我们发现本地 IDE 的发展并没有走到尽头，它与人的协同和体验提升仍有很大的挖掘空间。比如，多行补全功能在过去通常是基于光标位置逐行进行补全，但 Cursor 实现了在多个地方进行多行补全，我们也跟随这一思路，在 JetBrains 上开发了类似的多行补全能力。另一个例子是“apply”功能，过去在聊天对话中，用户很难将大模型生成的代码插入到文件中，因为需要找到合适的位置并解决编译问题。但 Cursor 通过一键“apply”功能，可以直接将生成的代码插入到当前文件中，这大大提升了用户体验，我们也在这方面进行了很多类似的探索。

其次，多模态模型的能力在不断进步。 过去，多模态模型很难理解复杂的架构图，但最近我们发现这一能力有了突飞猛进的发展。在实际业务中，许多系统（包括监控系统）的设计初衷是为了方便人类理解波动等信息，但模型很难理解这些信息。如今，多模态模型的价值逐渐显现，它能够解决许多问题，包括前面提到的文档中的图片问题和业务架构图问题。在解决业务上下文或场景上下文时，模型也能够更容易地理解用户意图，比如通过直接截图来理解用户在特定场景下遇到的问题。

第三，技术的进步使得端到端代码生成能力越来越强。 虽然模型在生成某些 logo 时可能仍有不足，但在样式、布局和文字方面，生成的结果已经非常接近原图。

第四，大模型开始擅长思考并解决复杂问题。 这主要得益于推理、模型的发展。过去，大模型更擅长快速思考，但如今它们开始学会像人一样进行深入思考。人在理解复杂问题时，如果仅靠概率判断，结果往往是不准确的。如今，大模型通过处理更长的 tokens，激发了其思考能力。一个典型的例子是，当直接询问 ChatGPT 等模型“1 亿以内最大的字数是多少”时，过去的模型可能会给出一个错误的结论。但现在的模型会告诉你它无法直接给出答案，而是提供一个 Python 脚本，通过脚本来解决问题。这表明模型开始了解自己的能力边界，这对于 Agent 的发展是一个巨大的助力。因为在处理复杂的长任务或 Agent 任务时，如果模型不了解自己的能力边界，可能会在许多步骤中给出错误的结论。

从 Copilot 到 Agent 的转变

虽然我们集团内部有大量用户在使用 AI 产品，但他们并不满足于目前仅能解决类似 Copilot 这样的问题，也不满足于仅能实现 20% 到 30% 的效率提升。因此，随着大模型能力的显著提升，包括多模态能力、复杂任务指令的理解能力，以及模型对自身能力边界的认知，我们今年上半年设定了一个重大目标：全面向 Agent 模式转变。

在过去的技术发展中，我们经历了几个阶段。最初是人驱动阶段，在代码补全中，完全依靠人工编写代码，并由人决定是否采纳。随后进入人与模型共同驱动阶段，模型开始参与部分流程决策，例如提供一批工具供用户在遇到问题时使用，由模型判断应该使用何种工具，但整体流程仍然是固定的。这种模式本质上是基于规则的编排，无论是编写脚本还是通过拖拉拽的方式，都是人与模型共同驱动的。这种基于规则的模型在短期内能够提升效率，例如在垂直场景中能够快速见效。然而，我们逐渐发现这种模式也限制了模型的能力，例如在调用 RAG 等技术时，虽然能解决一些问题，但灵活性不足，无法应对需求或上下文的变化。此外，流程编排还面临以下问题：

• 泛化能力不足：流程编排无法解决泛化问题，稍微改变需求或上下文，流程就可能不再适用。

• 成本高昂：为每个场景单独构建流程的成本非常高，且依赖人工，而人的表现往往不稳定。

• 复杂任务难以应对：对于稍微复杂一点的任务，基于规则的驱动模式很难奏效，因为规则无法穷尽所有情况。

我们还注意到，像 Devin 这样的工具通过模型驱动的方式取得了成功。Devin 能够从零开始生成代码，在其容器环境中进行调试，帮助用户生成需求和技术调研。这种完全依赖模型驱动的模式，能够在独立环境中执行复杂任务并取得成功。因此，我们决定摒弃基于规则编排的模式，转向模型驱动的 Agent 模式，以更好地利用模型的能力，提升效率和灵活性。

我们开发了两个 Agent 产品。第一个是基于 IDE 的 Agent 模式。在这个模式下，用户可以在 IDE 中提出需求，我们通过模型驱动的方式调用 Shell 能力、代码库的搜索能力，以及编辑字段、读取字段等能力，来自动帮助用户实现需求。这个 Agent 主要应用于以下几个典型场景：

• 小需求的实现：快速响应用户的小型需求。

• 仓库理解：帮助用户理解代码仓库，这是目前用户使用最多的功能之一。

• 场景左移：我们希望通过 Agent 将许多场景提前到开发早期阶段。在脱离 IDE 后，业务上下文和工程上下文的问题很难解决。例如，在代码审查时，如果大模型仅获取代码的差异，而没有工程上下文，就很难理解代码修改的影响范围。我们需要找到代码的调用链路，但在脱离 IDE 后很难实现。如果能够在 IDE 中将 IDE 本身的定义（Definition）和引用（Reference）等信息暴露给模型，让模型能够使用这些工具，理论上它应该能够自动找到代码审查过程中复杂的调用链路关系，发现更深层次的问题。因此，我们希望将代码审查和缺陷扫描等任务左移，让 Agent 在 IDE 中发挥更大的作用。这个 IDE 上的 Agent 是通过不断反馈和逐步执行的方式运行的，即每执行一步就反馈一次，逐步推进任务。

我们还启动了另一个产品，名为 Aone Agent。Aone Agent 与 Devin 非常相似，因为我们一直在强调通过模型驱动来解决复杂问题，并让 Agent 具备自主思考、自主规划、使用工具、反思和自我学习的能力。目前，我们已经实现了这样的程度：用户可以提出一个需求，需求提交后，系统会在后台启动一个容器，容器启动后会运行一个引擎。例如，如果用户要求生成一个五子棋游戏，引擎会生成代码，并在容器中启动一个 React 系统。启动后，系统会运行五子棋游戏，进行测试，查找代码问题，并反思整个过程。用户只需提出需求，例如“帮我生成一个五子棋游戏”，Agent 就能通过模型驱动解决这个长任务的复杂链路问题。整个过程大约持续半小时，但代码的生成、调试和预览都是由 Agent 自动完成的。这就是我们在开发的另一个产品——通用 Agent。

我们没有将这个产品的定位放在只能做某一个工作，我们把它的定位放在一个全研发全生命周期的提效，所以要求它既可以做业务调研。

也能做技术调研报告的生成：

做行程规划：

通过需求描述实现后端需求代码：

通过设计稿实现前端代码并调试和预览：

只有这种在一个产品里 All In One 的实现 Agent 产品才能实现效率的最大化，才能让一个人成为一个团队并提升十倍效率。

我们来对比一下两个 Agent 产品，如下表所示：

建设 Agent 遇到的挑战

在通用 Agent 的发展过程中，我们遇到了一些挑战和问题。我们原本认为通用 Agent 应该具备异步处理复杂任务的能力，但在实际操作中，我们遇到了工程和模型两方面的问题。

架构设计中包含了 Multi-Agent 的概念。任务首先交给一个 Leader Agent，它负责将任务分发给子 Agent，并在服务端进行数据收集，例如理解代码仓库和当前环境，然后进行任务规划、拆解和分发。子 Agent 可以执行各种任务，如 terminal 操作、shell 调用、文件操作、Web 服务调用以及 MCP 协议的 Agent 调用，并在容器中执行底层工具。Agent 架构需要解决几个关键问题，包括记忆控制、记忆存储（短期和长期）、任务分发、任务容器调度、事件分发与收集、协调控制、子 Agent 管理和通信，以及核心服务层的工具使用、收集、整合和通信。

通用 Agent 面临的几个关键问题包括：

记忆管理：在通用 Agent 中，记忆分为短期记忆和长期记忆。短期记忆对于处理多步骤任务至关重要，因为它可以防止 token 上下文过度膨胀，避免过多细节干扰模型判断。人类在解决复杂问题时，也会在潜意识中对过去的步骤进行压缩，只保留关键信息。长期记忆则用于存储成功解决复杂任务的经验，以便未来的任务可以借鉴这些经验。长期记忆也面临召回问题，即不同环境下的记忆是否能够复用，以及如何选择性地召回记忆。

• 任务执行：整个执行过程在一个容器中进行，需要有效的任务调度和事件管理。

• 子 Agent 管理：需要对子 Agent 进行有效的管理和通信，以确保任务的顺利执行。

• 工具整合：核心服务层需要整合和使用各种工具，以支持 Agent 的多样化任务。

这些是我们整个架构的核心组成部分，也是我们需要解决的关键问题。通过有效地管理记忆、调度任务、协调子 Agent 和整合工具，我们可以提升通用 Agent 处理复杂任务的能力，并使其能够从成功经验中学习，不断优化任务执行策略。

在评估 Agent 时，尤其是当任务多达上百步或者任务链路非常长时，我们面临两个主要挑战。首先，我们如何找到标准的输入输出来评估 Agent 的能力，即 Agent 是否能够解决当前的复杂问题。其次，我们如何评估 Agent 的效率，因为仅仅有能力是不够的，Agent 还需要在合理的时间内解决问题。

在过去，对于大模型的评估通常是基于一些评测集，如 HumanEval 等，这些评测集有标准答案或近似标准的答案。然而，在 Agent 的评估中，我们需要解决的问题更为复杂。我们不仅需要评估 Agent 的结果，还需要评估其过程。例如，一个简单的任务人类可能半小时就能解决，但如果 Agent 需要一天时间才能解决，那么其效率显然是不足的。为了应对这些挑战，评估方法包括两个方面：

• 结果评估：我们通过一些用例集来评估 Agent 的能力，这些用例集可能包括从零到一的代码生成任务、需求调研或技术调研等任务。通过这些任务，我们可以评估 Agent 是否能够完成这些工作。

• 过程评估：由于 Multi-Agent 架构可以将任务分解，我们也会在不同的环节生成用例集，对 Agent 的中间过程进行评估。这样，我们不仅可以了解 Agent 是否能够完成任务，还可以了解它是如何完成任务的，以及完成任务的效率如何。

在工具使用方面也存在挑战。Agent 在执行任务时需要使用大量工具，包括浏览器、shell 和 terminal 等。然而，Agent 在当前阶段对于这些工具的使用能力还有所不足。我们也注意到许多创业公司正在开发面向 AI 的浏览器。例如，当我们要求 Agent 申请一个五子棋游戏并预览时，如果游戏打开出错，人类可能会立即打开浏览器的控制台查看错误信息，但对于 Agent 来说，它很难知道接下来该如何解决问题。另一个挑战是工具之间的通信问题。当主 Agent 指示子 Agent 进行系统测试时，如果之前生成的用户名和密码没有传递给子 Agent，子 Agent 可能会不断尝试不同的用户名和密码来登录，而不是询问主 Agent 获取正确的凭据。这涉及到 Agent 与工具之间通信的问题。

在大模型方面，我们也面临一些挑战。首先是指令跟随能力的问题。例如，当我们指示 Agent 生成一个 HTML 邮件时，如果明确指出不要使用转义符，但 Agent 仍然坚决使用转义符，或者当我们要求 Agent 按照五子棋规则进行测试时，Agent 却逐个尝试无效的黑白棋步，这些都是我们在过程中遇到的问题。此外，还有指令上下文长度的问题。当给模型提供非常长的上下文时，模型捕捉隐藏细节信息的能力较弱。例如，如果我们给模型一个复杂的文件，并要求它生成调用链路图，模型可能会忽略很多细节。但如果我们先从文件中剔除一些注释或不重要的信息，然后再让模型生成调用链路图，它就能够找到更多关键的链路信息。

在模型推理和反思能力方面，我们认为 Agent 面临两个主要问题。首先，Agent 在寻找解决方案时可能会误入歧途，而且可能无法意识到如何回到正确的轨道上，这表明其反思能力不足。其次，Agent 可能会陷入死循环，例如在下载失败时不断尝试，而不是寻找其他解决方案。这种推理和反思能力的不足是 Agent 解决复杂问题的关键障碍。

我们担心的一个问题是，在解决通用 Agent 的复杂任务场景时，许多算法团队可能还没有充分意识到长任务链路上解决问题能力的重要性。过去的模型训练通常以降低损失（Loss）为目标，这在处理局部最优解的单步任务（如聊天机器人或代码补全）时是有效的。然而，Agent 模式涉及的是长链路任务，可能需要多步骤、反馈、反思和重新规划，这些都是复杂任务的一部分。当前的大模型擅长解决局部问题，但对于全局最优解的 Agent 目标则显得不足。

另一个担忧是，具备 Agent 能力的模型并不多，所以这块暂时比较依赖国外模型，我们与许多算法团队交流后发现，他们可能还没有意识到在长任务链路上解决问题的能力的重要性。我们希望国内的算法团队尽早重视这个问题，解决 Agent 实际会遇到的问题。

依赖外部模型来运行 Agent 存在几个问题：

• 成本问题：这些模型非常昂贵，例如，使用 Claude 服务的一个任务可能需要 50 到 80 元人民币，复杂任务的 token 和输出特别长，步骤也特别多，导致成本高昂，难以大规模推广

• 隐私问题：使用外部闭源模型可能涉及数据隐私问题，这是许多开源 Agent 创新团队共同面临的问题。

• 限流风险：外部模型可能存在限流风险，因为外部模型提供商可能也在尝试开发自己的 Agent 产品，他们拥有强大的模型，这给他们在 Agent 领域带来了优势。

• 被降智的风险：如果将来与模型提供商成为竞争对手，他们可能会降低我们依赖的模型的智能水平，这是我们无法探测到的。

我们认为，通用 Agent 在实现异步任务时，可能会带来 10 倍的效率提升，这是一个非常理想的状态，即我们只需将任务交给 Agent，让它自己调用工具并与公司内部业务整合，从而实现大幅效率提升。然而，这存在一个严重的问题，即安全风险，包括自动驾驶可能存在的不可预测性和异步执行的不可控性，我们无法实时监控。此外，还有隐私问题，例如 Agent 可能会过度收集数据，如财产数据、HR 数据等。还有一个授权边界问题，用户可能不清楚 Agent 被授予的权限将用于什么，例如，我们给 Agent 删除仓库的权限，但不知道模型何时会使用它，这存在一个信任问题。最后一个问题是责任归属，如果我们将任务交给通用 Agent，它能够大幅度提升效率，那么操作者是人还是 Agent？如果造成不可挽回的损失，责任应该归咎于 Agent 还是人？这是我们在理论上或业界应该共同面对和探讨的问题。

招聘：

此刻，人类正站在人机协作进化的转折点——Agent 不是迭代，而是划时代的范式革命！这是继图形界面、移动互联网之后，我们这一代人亲手定义未来技术范式的终极战场。

你是否厌倦了在技术舒适区重复劳动？是否渴望在职业生涯中触摸真正的技术奇点？如果你对重构人机关系底层逻辑感到好奇，如果你对解决这些未知又复杂的问题感到兴奋，不论是算法还是工程，都欢迎加入我们。

有意者欢迎联系：gengugu@foxmail.com

嘉宾介绍

向邦宇，阿里巴巴代码平台负责人，在代码管理、代码结构化数据处理、代码搜索、代码评审以及编辑器技术等领域拥有丰富的专业知识和实践经验。在阿里，他负责了包括 CloudIDE、代码搜索、CodeReview 等多个关键产品的开发与管理，成功引领了代码智能平台的建设与发展。他主导实现的阿里内部多个前沿 AI 应用，包括代码续写、Extensions、Workspace 等等，在阿里内部被广泛使用，提升开发者的效率和质量。

演讲征集

日前，由极客邦旗下 InfoQ 中国主办的 QCon 全球软件开发大会在北京圆满落幕。140 多场精彩演讲放送，直击行业痛点，为现场 1600+ 参会者传递可复制的经验与模式。10 月 23 - 25 日，QCon 上海站即将召开，如果你有相关案例想要分享，欢迎提交演讲申请。