作者 | AICon 全球人工智能开发与应用大会

策划 | 李忠良

编辑 | 宇琪

从数年前的斯坦福小镇，到今年爆火出圈的 Manus 和 MCP，Agent（智能体）已然成为当下人工智能的代名词。然而，当 Agent 成为所有人讨论的焦点时，其本质反而愈发难以看清。究竟何为 Agent？未来 Agent 生态将如何演变？又哪些机遇值得我们提前抢占先机？

近日 InfoQ《极客有约》X AICon 直播栏目特别邀请了商汤科技研发总监王志宏担任主持人，和腾讯云智能体平台产品中心总经理王磊、彩讯股份 AI 产研部总经理邹盼湘一起，在 AICon全球人工智能开发与应用大会2025 深圳站即将召开之际，共同探讨 Agent 应用工程化落地的架构范式。>

部分精彩观点如下：

在专业门槛高、劳动重复、价值感低的场景中， Agent 正好可以发挥巨大作用，以智能化手段解决低效问题。

Workflow 太刚性，面对复杂问题往往无能为力。此时，自主规划 Agent 的分析与执行能力就能带来更强的灵活性和创造性。

强化学习提供了一种以“任务为导向”的模型优化路径，更适配当前 Agent 的任务规划逻辑。

当前的重点，是以技术手段实现预期结果，然后再思考是否可以进一步规范化、协议化，促进各系统之间更顺畅的协作。

在 8 月 22-23 日将于深圳举办的 AICon全球人工智能开发与应用大会上，我们特别设置了 专题。该专题将涵盖多 Agent 协作系统设计、AgentOps 等多个话题，畅谈 Agentic 应用产业化落地的无限可能。

查看大会日程解锁更多精彩内容：

https://aicon.infoq.cn/2025/shenzhen/schedule

以下内容基于直播速记整理，经 InfoQ 删减。

Agent 的定义与价值

王志宏：当前行业中，“Agent”常被提及。Agent 的概念是什么？Agent 与传统 IT 服务或 AI 服务有什么本质区别？

王磊：可以从狭义和广义两个维度来理解和定义：狭义上的 Agent，能够自主与环境交互，独立进行编排和决策，以完成特定的任务目标；而广义上的 Agent 更加通俗，通常被泛指为大模型应用，它包括两类：一类是前面提到的狭义 Agent，另一类是利用大模型技术，通过 Workflow 编排来完成任务的应用。

2023 年，OpenAI 最初提出 Agent 的概念时，也给出了一个更泛化的定义：Agent = 语言模型（language model） + 执行器（executor）+ 计划模块（planner）+ 工具（tools）。我认为这个定义很契合目前业内对 Agent 的主流理解。

邹盼湘：如果将传统的 IT 系统视为一种工具，是我们用来完成工作的辅助工具，那么 Agent 更像是一个“伙伴”。它不仅可以与我们互动、协作，还能够自主完成某些任务。理想状态下，Agent 无需人工干预，就能实现自主感知、任务规划、执行和调整。

从结果导向来看，Agent 是以目标为核心的系统。它具备将抽象目标转化为具体行动的能力，而不是简单地响应输入。例如，它不只是执行某个按钮命令或应答一句指令，而是可以根据实际情况动态调整策略，以达成用户设定的预期目标。

Agent 还应具备动态适应和持续学习的能力，它能够根据环境反馈或用户在使用过程中的输入，不断学习每位用户的行为模式和历史信息，自动记录并优化自身的决策策略，从而实现更高效、更精准的任务完成。

相较于传统以开发者驱动为主的 IT 系统，Agent 更体现为一种“以模型驱动”的开发范式。它依赖大模型以及其他基础模型，能够自主规划、调用、反思，并提升整个系统在决策方面的智能化水平。

王志宏：哪些行业或场景会对 Agent 的需求最为迫切，通过 Agent 解决了哪些核心痛点？

邹盼湘：我认为未来几乎所有行业都会通过 Agent 进行业务重构。如果要选出几个应用最迫切的领域，首先是企业知识库。现在大多数企业的知识尚未得到充分利用，一方面缺乏有效的沉淀机制，另一方面即便沉淀了，也缺乏明确的场景或链路将这些知识的价值释放出来。

通过基于大模型的企业知识库类 Agent，可以显著提升知识获取效率，同时保障企业知识的传承和组织智慧的积累。此外，它还能帮助实现信息的一致性与准确性，加快新员工培训、工具使用赋能、开发规范理解等流程。跨部门协作方面，不同部门拥有各自的知识库，Agent 可以帮助了解其他领域的流程和信息，促进协作。

另一个典型场景是企业智能 BI（AIBI）。随着企业规模扩大，数据分析工作日益复杂，传统上需要数据分析师、数据挖掘师乃至数据库工程师，负责数据查询、建库和挖掘价值。而通过 Agent，我们可以重构整个流程，使企业内的每一位员工都具备“数据分析师”的能力。

Agent 可根据用户需求，快速提供所需数据并释放其价值。即便是非技术人员，也可以基于不同维度，轻松获取并理解数据潜在含义，比如掌握当日销售情况或市场波动，实现数据的民主化应用。

此外，Agent 还能优化资源配置，例如预测库存水平、制定营销预算，并根据不同预算或活动策略进行资源分配，避免浪费。过去这些工作依赖专业团队，周期以“月”为单位，现在通过 AIBI 可以将数据分析的响应时间缩短至“小时”级别。

王磊：目前 Agent 落地最广泛的场景之一，就是与知识服务相关的部分。企业的知识服务大致可以分为两类。第一类是面向外部用户，主要包括政策类咨询服务，例如公积金、社保等政府政策，或企业产品的售前售后咨询，这类服务核心在于知识的对外传递和答疑。

第二类是面向企业内部的知识服务，又可以细分为两类：一是业务知识问答，例如保险企业内部关于定损、合规、政策解读、赔付规则等方面的知识查询；二是办公效率提升类应用，如合同审查、项目周报、会议纪要整理等。这些看似琐碎的工作日常高频发生，但若通过 Agent 处理，可有效释放员工的时间和精力。

现在业界也广泛部署了“代码助手”类的 Agent，这一类应用在国内外发展迅速，能够自动生成约 25%–30% 的代码，其质量和采用率也都较高。本质上，这些应用都是在解决实际问题，创造新增价值。

在我们的观察中，Agent 的价值主要体现在两个方面。第一是降本增效：很多重复性任务并不需要人工完成，使用 AI 来处理既高效又降低人力成本，人类通常也不喜欢这类机械性工作。

第二是知识辅助：企业中很多岗位对知识的记忆和积累要求极高，比如要成为某一领域的专家可能需要上万小时的训练，但这类专家资源一旦缺位，或新人入职时经验匮乏，就容易出现断档。Agent 在这种场景下可以作为辅助力量，帮助企业保持知识传承和业务连续性。

此外，在产品创新方面，Agent 也具有重要意义。比如现在的交互方式已经从传统操作界面转向自然语言，甚至语音驱动，未来还会融合视觉，实现多模态的智能交互体验。

这些变化将极大革新人与系统之间的交互方式。我自己在使用 AI 工具时就明显感受到，它们比传统工具更易用、更吸引人，这正是产品创新带来的价值。

王志宏：我今年一直在推进 AI 的私有化落地，也接触了不少客户。他们普遍存在一个特点：很多核心业务场景高度依赖专业人才。虽然需要资深专家处理问题，但这些问题往往重复且枯燥。

比如专家要不断地培训新人，解答常见问题；医生要反复面对不同病人的基础问诊；律师则需要频繁为客户查阅法律文件、做出解释。这些工作虽然对专业性要求高，但价值密度却不高，其中可能有 80%–90% 是重复劳动。

这就造成了一个矛盾：会做的人不愿意做，不会做的人做不了。我们可以通过训练行业 Agent 来缓解这一问题，让它们充当专业人才的智能助理，承担重复、标准化的部分工作。

很多行业任务虽然需要专业知识背景，但其中有大量结构化、流程化的操作，而这正是 Agent 能发挥作用的地方。它可以通过学习知识库、流程经验等先验知识，去自动完成一部分专业工作。

这些场景共同的痛点是：专业门槛高、劳动重复、价值感低。而 Agent 正好可以在这类场景中发挥巨大作用，以智能化手段解决低效问题。

企业落地的技术与实践挑战

王志宏：目前市面上 Agent 两种形态：基于 Workflow 构建的 Agent 和自主规划 Agent，这两类 Agent 构建的核心技术差异是什么？分别适用于哪些场景？

王磊：基于 Workflow 构建的 Agent，通常是通过 DAG（有向无环图）流程来完成任务编排。而具备自主规划能力的 Agent，则是依靠模型本身的主动思考和时间规划来推进任务。这两种方式在技术路径上有本质差异。

具体来看，基于 Workflow 的 Agent 本质上是规则驱动的自动化流水线。开发者在构建时已明确整个流程的步骤、每一步的输入输出以及执行动作，因此核心依赖规则引擎。

此外，还需要模块化的编排工具，使开发者能灵活组合节点来完成特定任务。除此之外，Workflow 系统还要具备健全的异常处理机制，以应对复杂的边界条件。

而自主规划型的 Agent 则更依赖于强化学习和因果推理能力。通过奖励函数来优化策略，再结合反思机制不断纠正错误，实现自我优化。此外，它还需具备动态任务分解能力，能够将任务拆解为若干动作或子任务，逐步执行，最终完成整体目标。在此过程中，Agent 要能判断何时调用哪种工具，确保任务得以顺利推进。

从长远看，我们当然希望实现具备自主思考与规划能力的第二类 Agent。但在当前实践中，由于大模型存在幻觉问题，难以保证准确性和可控性，而企业对可控性和精度要求很高。

因此在现阶段，基于 Workflow 的 Agent 反而应用更广，具备较强的工程可行性。

邹盼湘：从构建路径来看，Workflow 型 Agent 相当于预设了一套任务流程，而自主规划型 Agent 则具备一定的思考能力。Workflow 的构建不仅需要一个编排画布，方便快速设计业务流程，还需要强大的执行引擎来运行这些流程。

我们在构建 Workflow 时，会考虑串行、并行、回环、全局跳转等模式，以支持多样化的业务需求。

而自主规划 Agent 的底层逻辑则是 REACT 框架：推理、执行、观察、循环与工具调用。它强调激发大模型的能力，让其自主调用资源，通过不断迭代完成复杂任务。

相比之下，这类 Agent 具备更强的泛化能力和灵活性，适用于任务复杂或意图模糊的场景，不再是简单的 API 映射。

王志宏：Workflow 型 Agent 的优势在于流程明确，它能将专家经验转化为固定的行为路径，每一步输入输出都清晰可控。开发者可以通过可视化工具如拖拽连线，或基于开源框架如 LangChain、LambdaIndex，或自研工具如 LazyLLM 编排完整流程。

这种模式适用于需要高准确率的企业服务场景，尤其是批量处理成千上万个任务时，对系统稳定性和结果一致性要求极高。

Workflow 太刚性，面对复杂问题往往无能为力。此时，自主规划 Agent 的分析与执行能力就能带来更强的灵活性和创造性。

因此在实际落地中，我们常常将两种 Agent 结合使用，在 Workflow 中嵌入具备思考能力的节点，在自主 Agent 中集成流程引擎，二者相辅相成，现在很多框架都支持这样的融合开发。

王志宏：对于 Agent 系统来说，RAG、强化学习、分布式推理这些技术分别起到什么作用，为什么今年各大厂商和研究机构会大力推崇强化学习？

邹盼湘：从 Agent 的几个关键组件来看，RAG 本身可以独立构建成一个应用。但在我们当前的 Agent 开发实践中，RAG 更多是作为数据来源的工具，用于为 Agent 提供推理和规划所需的背景知识。

相比传统意义上主要依赖本地知识库进行检索的 RAG 应用，我们目前采用的方式更加多样化。除了从本地知识库中召回信息外，还引入了 Agent 记忆机制，甚至整合了互联网的多源知识。这种整合方式有助于 Agent 获取更全面的决策依据。

至于强化学习，它的核心作用在于提升模型在特定垂直领域的推理能力。在 B 端应用场景中，企业通常有专属的业务流程、系统与数据。大模型要充分理解这些复杂的上下文，面临较大挑战。通过强化学习的方式，可以逐步增强模型在行业特定任务中的“智力上限”。

另外一个关键技术是分布式推理，它主要用于两个方面。一是支持多 Agent 系统的运行，这类系统往往对计算资源和协同机制要求较高；二是优化性能表现。相比传统 IT 系统，当前的 Agent 系统响应速度慢、算力消耗大。分布式推理有助于提升响应速度和并发能力。

对于复杂任务，我们不再依赖单一模型处理全部问题，而是将其拆分成相对独立的子问题，通过多 Agent 协作解决。这种松耦合的结构更具可扩展性与可维护性，也使系统能动态应对环境变化。

多 Agent 之间的协商机制，能够实现整体任务的最优执行。它不仅使系统对环境更加敏感、灵活，也更容易适应业务需求的变化，强化学习在其中的角色也逐渐重要起来。从去年底到今年初，业界对强化学习的讨论明显增多，部分原因是传统的模型训练路径面临瓶颈——数据集已被广泛使用，新数据稀缺，旧的扩展方式难以为继。

而强化学习提供了一种以“任务为导向”的模型优化路径，更适配当前 Agent 的任务规划逻辑。因此，它逐渐成为大模型厂商提升推理能力的主要方向。

王志宏：RAG 是一种非常典型的广义 Agent，在企业中的落地效果尤为显著，原因在于企业通常拥有大量专有知识，这些知识往往因保密需求无法用于大模型的训练。例如航空航天、基建、铁路等行业，企业数据长期封闭于局域网之中，使得现有模型难以有效回答行业相关问题。

客户普遍反馈，大模型在通用领域表现优秀，但在本行业则常出现知识不足甚至错误的情况。因此，许多企业倾向于构建自有 RAG 系统，用作企业知识库，这类知识库在私有化部署场景中尤其受到青睐。

相比其他 Agent，RAG 更易稳定落地，尤其在准确率要求高的业务场景中表现优异。Agent 可以提升 RAG 的能力，例如在初次问答质量不高时，Agent 可对用户问题进行拆解、判断回答准确性，并通过迭代优化生成结果；同时，RAG 也可为 Agent 提供知识支撑，例如作为工具知识库，帮助 Agent 从海量工具中选择最合适者。

考虑到大模型的上下文长度有限，如果需要从成千上万个工具中选出合适的一个，就必须借助一个结构化的工具描述库，而这正是 RAG 的用武之地。通过存储每个工具的名称和功能简介，RAG 可辅助 Agent 做出更优的工具选择。

此外，RAG 还能作为记忆模块，减少 Agent 的工具选择错误，提升决策稳定性。因此，RAG 本身既是一个 Agent，也可以与其他更复杂的 Agent 配合，共同完成高难度任务。

关于强化学习，我认为其核心价值在于降低标注成本。在大模型训练中，算力和高质量标注数据是主要瓶颈。强化学习通过引入沙箱环境和奖励函数机制，让模型在无需人工标注的情况下自行学习。

例如，当模型输出正确时给予奖励，错误时施以惩罚。这样一来，模型便可通过试错优化策略，极大降低人力成本。对企业而言，这种方式实实在在地“省钱”，因此强化学习也越来越受到青睐。

王志宏：在多 Agent 系统中，存在规划驱动（中央规划）与自治驱动（各 Agent 自主决策）两种模式，更看好哪种模式在企业级场景中的落地？为什么？它们在实际部署中各有哪些优势和挑战？

王磊：在规划驱动（Plan-and-Execute）模式中，系统通常由一个计划器（Planner Agent）和一个执行器（Executor Agent）组成。用户发出请求后，计划器会对任务进行分析并生成任务列表，再将其交由执行器完成各项子任务。任务全部完成后，结果返回给计划器，由其进行总结并生成最终响应，返回给用户。

而多 Agent 协作（Multi-Agent）模式，通常包括一个主控 Agent（或称入口 Agent）与若干专家 Agent。通过配置 handoff 机制，各个 Agent 能够根据任务判断是自行处理，还是转交给更合适的 Agent，由此实现复杂任务的协作完成。

在多 Agent 模式下，我们可以调用具备特定功能的协同 Agent，例如一个内嵌 Workflow 的 Agent。至于两种模式孰优孰劣，其实更多是“选择题”而非“标准答案”，因为它们各有优劣。

从灵活性角度来看，Multi-Agent 模式配置灵活、上手简单，但对底层大模型能力依赖较高，输出效果易受影响；Plan-and-Execute 模式则相对定制化、配置不够灵活，但对模型的要求较低，落地效果更稳定，尤其适合当前大模型能力尚不完全可靠的阶段。

从执行速度来看：Multi-Agent 更适合快问快答场景，响应速度快，通常为同步执行。Plan-and-Execute 更适合需要深入推理、系统分析的任务，通常响应较慢，采用异步机制。

邹盼湘：目前从我们正在推进的项目和产品规划来看，市场上的主流仍然是规划驱动的模式。这种方式通常由一个监督者进行任务的分发与调度，主流的多 Agent 平台基本上也采用这种模式。

具体来说，这种模式中会有一个名为 planner 的主 Agent，负责对用户需求进行整体规划、任务拆解，并将各个子任务分配给对应的子 Agent 执行。

主 Agent（planner）会根据任务特点，选择最合适的子 Agent 来完成相应的工作。如果执行失败，它会根据失败反馈重新判断，是继续由原子 Agent 执行，还是重新分配给其他 Agent。这个主 Agent 就像一个大脑，或者说是一个“组长”，统一安排任务和调度资源。

自治驱动，则可以类比为一个团队在没有明确组长的情况下，自主协商如何完成任务。各个 Agent 之间可以自由通信，而不是被动等待任务分配。类似于一个课题组，成员们共同讨论并决定谁负责分析、谁执行、谁测试等。

这种模式目前还主要应用在探索性或较浅层的场景中，尤其在 B 端的垂直业务场景里，我们会更加谨慎地使用这种模式。

这两种模式的本质区别在于通信方式：规划驱动是单向通信，由主 Agent 向下指令；而自治驱动是双向或多向通信，Agent 之间可以互相交流。从实际使用效果来看，尤其是在实现多 Agent 协同和打通各业务系统的需求下，我们认为仍需要一个统一的“组织者”角色来接收任务并进行协调。这是因为真实场景中除了数据流转和任务规划，还涉及权限控制和安全等复杂问题。

如果权限放得过宽，允许各个 Agent 自由通信，可能会带来权限滥用、注入攻击或敏感信息泄露等风险。因为系统并不知道应当向哪个 Agent 传递哪些信息，这就是在组件化模式下的一个关键挑战。

但从未来技术发展趋势来看，自治驱动模式无疑是一个重要方向。它能够极大地激发创造力，提高多系统协同处理能力。

相比于由主控体统一规划的方式，自主协作可以解放任务边界，更容易激发团队潜力。例如，在一个研究小组中，若允许成员之间自由交流，往往能取得更多具有创造性和突破性的成果。

如果完全依赖组长指派任务，多 Agent 系统的能力上限将受到组织结构的限制。一旦主控体判断失误，整个系统的任务可能无法完成。换句话说，这取决于我们是信任“组长”的能力，还是信任“团队”的集体智慧。

从落地的可行性和投入产出比来看，目前仍是第一种模式更具实用性。自治驱动的模式虽然具备长远潜力，但其挑战也很明显：首先是更高的算力消耗与成本；其次，缺乏明确的沟通边界，难以控制沟通的对象和时长，导致任务的完成时间和标准难以界定。因此，当前它更多用于技术探索和研究方向。

王志宏：目前市面上仍以 PE（Plan-and-Execute）模式为主，无论是 Deep Research 还是 Manus 等平台，基本都采用这种架构。PE 模式之所以被广泛采用，关键在于它调试方便、安全性高、可靠性强，这些都是我们当前选择它的重要原因。

而多 Agent 系统对模型能力的要求非常高。在多个人协作的情境中，如果缺乏明确的负责人，即便表面上大家达成共识，实际上各自对信息的理解往往存在细微差异，结果就是需要频繁召开沟通会、对齐会，以确保所有人理解一致。

每个 Agent 对同一句话或任务的理解可能不完全一致。因此，系统必须具备一个强大的决策机制，比如在意见不一致时由谁拍板？如何判断已经达成共识？只有事先设定清晰的规则，未来在 Agent 能力足够强大的时候，Multi-Agent 系统才有可能在活力与创造力方面超越当前的 PE 模式。

此外，除了模型能力的差异，不同场景对模式的选择也有所不同。例如在 AI 游戏中，涉及多个 NPC 的互动，Multi-Agent 模式更为合适；而在处理明确、单一任务，如回答具体问题时，PE 模式可能更高效。

因此，选择哪种模式不仅取决于 Agent 本身的能力，也要考虑具体的应用场景。

王志宏：当前是否已有多模态输入、RAG 与外部工具调用融合的统一架构或行业标准？若尚未形成，主要技术和组织障碍是什么？

邹盼湘：目前，无论是 Agent、多 Agent，还是 Agent 与工具之间的协作，都在逐步走向标准化。近期较为流行的 MCP 协议，便是用于规范 Agent 与工具之间如何高效调度，以及如何构建更完善的工具生态体系。

同时，也有如 A-to-A AMP、ACPS 等 Agent 间通信协议，旨在规范多 Agent 之间的协作方式。

然而，具体构建方式及落地路径仍存在较大差异，这主要受到应用场景、现有业务系统、数据结构以及流程差异的影响。即便方向一致，也很难在技术路线层面实现统一。

比如 RAG 虽已提出多年，也是应用最广的一类技术路径，但在具体策略上，如多路召回、切片策略等仍无统一标准，因为不同文档类型和领域数据的切分方式千差万别。

召回方式也各不相同，既包括向量召回、传统的 BM25，也可能结合知识图谱等策略。虽然知识图谱在理论上被广泛提及，但在实际落地中使用频率较低。

此外，目前我们所提到的工具和流程，仍然强烈依赖于传统业务系统。构建 Agent 系统并非从零开始，许多 OA 系统、邮箱系统、HR 系统等早已建成，不可能因大模型的出现而全部推翻。

因此，我们更多是在现有系统的基础上做升级与改造，这就要求我们在系统、环境和流程层面进行适配，也正是技术路线难以统一的重要原因之一。

王磊：无论是 Agent 还是 RAG，大家都在尝试将其与大模型结合，进而构建解决具体业务问题的 Agent 系统，优化原有流程或提升产品体验。

然而在这个过程中，我们仍在不断验证技术效果，即是否真正带来业务或产品价值。如果不能带来实际成效，技术实现就失去了意义。因此当前的重点，是以技术手段实现预期结果，然后再思考是否可以进一步规范化、协议化，促进各系统之间更顺畅的协作。

MCP 协议的推出就是一个很好例子，发布后大家迅速达成共识，插件之间的互通得以实现，服务能力在跨平台、跨模型场景下显著提升，其可用性和可接入性都得到了极大增强。

目前仍处于技术和产品价值验证的初期阶段，这是第一点。第二点是“快”——AI 本身发展迅猛，而大模型是“卷中之卷”，在这个赛道中，无论是模型本身还是其应用形式都在快速迭代，大家几乎都在全速前进。

也正因为如此，规范的建立往往滞后于技术发展，大家还没来得及停下脚步去制定统一的接口或协同机制。但从长远来看，行业一定会逐渐走向规范化，就像互联网发展一样，最终会形成互联互通的生态。

王志宏：目前大模型的发展非常火热，技术迭代速度极快，这也导致现有的一些规范和约束机制难以跟上底层能力的快速演进。MCP 协议的出现，某种程度上反映出行业希望通过协议化的方式，使 Agent 系统的构建更加有章可循。

在开发 Agent 方面，目前市面上涌现了许多优秀的框架，比如 LangChain、LlamaIndex 等；除了代码层面的开发框架，也有像 Define 这样的应用编排框架，它们在敏捷开发中非常实用。

然而，实际情况是，很多企业在生产环境中并不采用这些框架，或者只是用它们快速搭建一个 demo，最终在真正上生产时往往选择放弃这些框架，重新自行开发，重新“造轮子”。

这种现象其实反映了敏捷开发与工业化生产之间的权衡：在快速迭代阶段，我们倾向于选择使用成熟且易用的开源框架；但在进入生产环境后，会发现这些框架难以支撑稳定性、安全性与一致性要求，也无法形成统一的技术架构或行业标准。

王志宏：构建可复用、易扩展的 Agent 平台时，您推荐哪些核心设计原则或参考框架？

王磊：在 Agent 系统设计中，其实已经逐渐形成一些核心的共识性原则。首先是分层解耦的架构设计，即感知、决策与执行相互独立。例如，在感知层可接入视觉等多模态输入，在决策层通过动态规划和任务路径管理，实现高效调度，而在执行层则通过标准化接口调用工具，并支持诸如事务管理、回滚等机制，以增强系统的稳定性和可控性。

其次是模块化设计和组件复用。我们倾向于对常用工具进行封装，形成可插拔、灵活组合的能力模块，从而提高开发效率和系统扩展性。再者是通信协议的标准化，我们正在全面拥抱如 MCP 这样的通信协议，以促进插件和服务之间更开放、标准化的交互。

此外，在多 Agent 协作方面，我们也探索了多种框架，包括基于 DAG 的任务流 Agent，实现底层的任务调度和协同。

由于 ToB 服务和产品对质量要求较高，我们也在建设全链路可观测性体系，覆盖创建、调试、优化和发布的全流程，以便于客户和开发者高效使用。这些都是我们目前所坚持的设计原则和实践路径。

邹盼湘：在 Agent 开发框架方面，我认为应避免回到传统的“意图分发”模式。即便在任务目标清晰、可控性要求高的场景下，我们也应尽可能让模型主导 Workflow 的驱动，调动多个工具协同工作。

此外，我们应当以“AI native”的理念来思考整个系统的构建，无论是数据处理、策略治理，还是应用层设计，甚至是 UI 交互，都应尽量摆脱对传统技术路线的依赖，以全新视角构建新一代 AI 系统。

在开源框架方面，市面上已有诸如去年较为流行的 Swarm、Node Graph 等多 Agent 协同框架。它们在实践中值得参考，但我们不应被任何一个框架限制，核心仍应围绕目标达成和技术可行性展开：我们要了解当前模型能力的边界，并据此制定合理的工程实现路径。

在构建中控 Agent 时，核心工作往往是“构建上下文”（context build）。不管是做 RAG、任务推理还是工具调用，最终都是在为模型创建一个有效的上下文环境。这包括从用户输入出发，通过 query 的重构和分解、知识的调取将信息聚合，形成新的上下文。

每一次任务的迭代，本质上都是一次新的 context 构建。因此，我建议大家可以将重点从传统的 prompt 工程转向 context 构建，逐步向“Context Engineer”的方向演化。

关于 AI 应用的构建范式，我认为可以根据具体场景进行拆解与规划。比如在工具使用和任务交付环节，我们在 Deep Research 项目中采用的是 PE 模式，但未来是否继续采用该模式，还是引入新的架构，要视其可控性和落地可行性而定。没有一种模式是通用答案，选择需基于现实需求和未来预期进行权衡。

最后，我认为 REACT 的思想应该被持续发扬，它结合了 reasoning 与 action，是一种非常契合 Agent 特性的机制。它支持信息反馈、任务迭代与优化，是实现人机对话与互动的核心思路之一。

王志宏：一个好的 Agent 平台必须足够简单，门槛要低。例如，配置好环境变量，输入 API key，再写两三行代码，就能在网页上输入问题并获取答案。这种“即插即用”的体验非常重要。

其次，平台需要提供一站式服务，覆盖从应用创建、效果验证、调优到发布的全过程。例如，我们希望用户能快速将想法变成应用，部署到客户环境中后，通过真实场景反馈进行迭代优化。

一个理想的框架应该具备完整的部署能力，支持一定并发量，同时拥有良好的扩展性。若框架封装过于严密，开发者很难添加新功能，必须改动源码，这显然不利于引入先进算法。相反，如果框架足够灵活，就可以轻松集成各种新兴的开源算法。

以 RAG 为例，我们可能会引入多路召回策略，每一路使用不同的文本切分方法，甚至提前总结关键词、QA 或提纲。框架应能支持这些灵活配置。

此外，框架需要灵活支持向量召回或传统方式。同时，应具备开放架构，允许各个组件可插拔替换。例如，一个客户需要使用 Newmas 数据库，另一个客户更适合使用 Fast，因为他们硬件资源有限；有的用 Elasticsearch，有的用 OpenSearch，框架都应能适配。

数据库方面，在私有化部署中，不同客户有不同需求。多数情况下 PostgreSQL 就够了，但对于强调自主可控的客户，我们也会推荐 TiDB 或达梦这样的国产数据库。组件要能灵活替换，同时保证使用体验一致。

大模型也要支持灵活切换。例如今天用本地模型 DeepSeek V2，明天想换成某个厂商的在线模型，应该只需修改配置，代码其他部分无需变动。理想状态是用户切换模型如同换插头，不影响整体流程。

会议推荐

首届 AICon 全球人工智能开发与应用大会（深圳站）将于 8 月 22-23 日正式举行！本次大会以 “探索 AI 应用边界” 为主题，聚焦 Agent、多模态、AI 产品设计等热门方向，围绕企业如何通过大模型降低成本、提升经营效率的实际应用案例，邀请来自头部企业、大厂以及明星创业公司的专家，带来一线的大模型实践经验和前沿洞察。一起探索 AI 应用的更多可能，发掘 AI 驱动业务增长的新路径！