提升Agent的可信度后，企业会多一批好用的“数字员工”吗？

随着 AI 技术从“工具化”向“自主化”严谨，智能体（Agent）正在成为企业应用大模型的重要形态。那么，如何优化 Agent，让它变得更可信、更好用，最终能够成为企业优秀的“数字员工”？

近日 InfoQ《极客有约》X AICon 直播栏目特别邀请、RBC senior application support analyst 马可薇担任主持人，和值得买科技 CTO 王云峰、商汤科技大装置事业群高级技术总监鲁琲、明略科技集团高级技术总监吴昊宇一起，在AICon 全球人工智能开发与应用大会 2025 北京站即将召开之际，共同探讨如何提升企业 Agent 的“可信度”。

部分精彩观点如下：

• 未来可能真的不再存在传统意义上的软件界面，UI 可能完全消失，取而代之的是由 Agent 与系统直接交互。
• 协议的价值在于让生态中的每个角色，提供大脑、数据、工具或执行能力的厂商，都能使用同一种语言沟通，使大家可以把精力集中在自身专业领域，而无需耗费大量时间做适配工作。
• 许多模型在长文本中间部分存在遗忘问题，大海捞针本身就是不现实的任务。尽管大家都宣称拥有超长 context window，但真正有效的部分其实没有那么多。
• 真正的难点是业务模型与技术模型如何统一、如何对齐。纯技术层面的参数对齐反而是最不需要担心的，毕竟大家都是写程序的。

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

定义 Agent 的技术边界

马可薇：很多人觉得 Agent 就是 Chatbot 加了几个插件。但从技术架构视角看，当系统目标从“对话”变成“行动”，你们认为技术栈上产生的最大一个质变是什么？

王云峰：我认为 chatbot 本身只是一个交互形态。过去大家在互联网上主要依赖点击，后来 AI 具备了对话能力，人们开始在对话框中和它交互；再后来端到端语音出现，AI 获得更强的多模态能力，使对话变得更自然、更强大；随后 Agent 的兴起又进一步扩展了它的可操作范围。

chatbot 只是一个界面，而关键逻辑在于背后的大模型。我们常把大模型比喻为“一个大脑”，而传统 chatbot 只是让用户通过简单的交互去压榨它的知识。但一个聪明的大脑需要外围系统，就像人需要眼睛、鼻子、触觉去感知世界，需要手脚完成操作。

完整的过程包括：模型接收任务，判断应采取的行动，感知外界、接收反馈，并基于反馈不断调整规划。这与过去单纯的 chatbot 模式有巨大差异，其技术复杂度和对生态的要求都远高于对话系统。

鲁琲：以对话为目的的 AI 与以行动为目的的 AI，其核心区别在于前者关注过程，后者关注结果。许多程序员应该还记得 GitHub Copilot 刚问世、没有 Agent 模式时的状态。当时它只有代码补全功能，本质上就是一个 chatbot。常见流程是：模型补全代码，如果结果不理想，程序员再向模型反馈并请它修改；代码执行报错后再把报错贴回去，让模型继续改，如此反复直到运行成功。

后来出现 Agent 模式，本质上仍是同一件事，只是 Agent 可以自动执行整套流程。之前的规划由人来做，需要人在脑中维护任务步骤、判断接下来要切换到测试、再根据结果回到编码等一系列上下文管理。

Agent 的出现把这些过程都包进了系统中：Agent 会自行规划、调用工具、管理上下文。核心在于模型具备了更强的记忆和上下文管理能力，把过去由人维持的短期、中期、长期记忆和状态切换能力转移到 Agent 内部。

因此，Agent 能够在一个循环中持续工作几十分钟甚至数天，并且始终知道自己做了什么、正在做什么、接下来要做什么，这体现了当前 Agent 技术栈的重大质变。

吴昊宇：这也与最近豆包手机爆火有关。豆包和努比亚联合推出的手机能够被 AI 直接操控，但随后微信、淘宝等平台禁止其登录。我体验了一会儿，确实很强，它已经不再是对话形态，而是能够根据你的指令在手机上逐步完成操作。

这意味着 AI 具备了任务规划和执行能力，在企业场景中同样重要。例如，当我们让 AI 判断某个话题的热度，它不能只是简单搜索并回答，而应该规划整套步骤，包括检索、汇集相关词和帖子、进行情绪聚类、生成报告等。与过去只做问答或简单文本分析完全不同，对规划与调度能力的要求显著提高。

其次，系统具备“动手”能力后，其权限与责任也随之扩大。AI 可以访问手机相册、聊天记录；在企业内部它可能访问工作软件、数据库。这意味着系统必须具备可追溯、可干预的能力，并设置明确的安全边界，否则行为将不可控。因此，在 Agent 架构中，我们加入大量监控、可验证机制以及人工闭环控制，这也是与过去 chatbot 模式最大的差异之一。

马可薇：目前的 Agent 经常“变笨”或“卡住”。从算力供给、数据供给、协议交互这三个环节看，目前的“短板”究竟在哪个环节？是推理速度太慢跟不上思考，还是上下文记忆太短限制了逻辑？

鲁琲：更准确地说，是高性价比算力的短缺。从实际落地的 Agent 来看，问题往往不在于是否有算力，而在于成本与效果之间的权衡。很多应用场景并不会使用旗舰模型，而是选择 30B 甚至 7B 这样更小的模型。尽管这些模型可能支持 100K 甚至 200K 的上下文窗口，实际使用时仍会将上下文限制在 32K 或更小的范围内，本质上是为了降低成本。同样地，我们也会限制 Agent 深度思考的轮次，比如在 Cursor 中开启 Max 模式、使用最好的模型让它生成一个 feature，执行二十分钟就能耗尽当月配额。如果未来有更多高性价比算力可用，现有的顶尖模型与算法才能在更广泛的场景中充分发挥能力。

吴昊宇：上下文的数据质量同样极为重要。即便上下文很长，如果信息质量低、噪声多，模型输出的任务规划和结果仍然不会理想。像我们做舆情分析时，常用的是小红书、微博等平台的帖子，但这类信息密度普遍较低。如果直接把一万条帖子全部丢给大模型做总结，得到的观点和事实要么不完整，要么存在偏差。因此，我们通常会对数据进行预处理，再交给模型生成总结或报告。

此外，Agent 的上下文往往来自先前多轮的交互，其中有些信息有用，有些只是无效尝试。现在虽然已有上下文压缩技术，但大多是被动的：在快达到窗口上限时才进行压缩。实际上我们需要更频繁地压缩，使保留下来的信息密度更高、更加真实可靠，从而提升 Agent 的规划能力。因此，要让 Agent 运行得更好，必须提供可信、高密度、高质量的数据。

王云峰：随着模型变得更强、上下文窗口更大，真正决定 Agent 效果的往往不是模型，而是企业内部的私有数据质量。模型是可以选择的，不行就换更好的，或者通过微调、蒸馏改善效果；但数据预处理的难度远大于选模型或微调模型。我们必须承认，未经处理的数据是完全无法使用的，而高质量数据的构建难度非常高。

尽管上下文窗口越来越大，如果输入内容过长，模型产生错误的概率仍然会上升。例如在一些需要了解用户需求的场景中，一万篇内容远不足以形成合理判断，合理的采样量级应该是十万甚至上百万篇。但当数据量达到百万级别时，直接输入模型的结果几乎不可用。并且随着处理链路变长，哪怕每个环节的可用性有 90%，经过十个环节后整体可用性也会下降到不可接受的水平。

一个 Agent 的完成需要多个环节、多个模块共同协作。大脑只是其中一个模块，还需要大量数据，而这些数据既包括企业私有数据，也包括金融、法律、隐私保护等方面的专业信息。未来每一种能力或模块都可能由不同厂商提供，例如大模型由一批厂商专注提供，让“智能大脑”越来越强，而数据提供方则确保数据真实可靠、信息密度高，还有一些数据来自实时感知。

在这样多方协作的体系中，协议的重要性就凸显出来了。没有任何一家厂商能够完成所有工作，生态必然需要众多参与者。如果每次调用外部数据或工具都要重新适配，将极大降低效率。因此协议的价值在于让生态中的每个角色，提供大脑、数据、工具或执行能力的厂商，都能使用同一种语言沟通，使大家可以把精力集中在自身专业领域，而无需耗费大量时间做适配工作。

马可薇：如果未来是多 Agent 协作的世界，Agent 之间沟通需要标准。王总在推 MCP (Model Context Protocol)，鲁总和吴总怎么看？2026 年，Agent 的互联协议会走向开源统一，还是大厂割据？

鲁琲：未来必然是多 Agent 协作的世界，而且 Agent 之间的关系将远比今天复杂，会呈现多对多、开放式的交互。因此，统一的 Agent 交互协议显得格外重要。我个人坚信协议最终会走向开源统一，走向中立、开放、自主的状态，而且速度很可能会非常快。

我们可以回顾互联网发展史。例如最初 TCP/IP 协议与 OCI 竞争了十多年，最终 TCP/IP 被交由 IETF 维护，形成中立治理。期间，硬件厂商和软件开发者都面临需要同时适配两套协议的困境。HTTP 也经历了类似的过程，花了很长时间才走向开源和自治。而更近代的协议如 Kubernetes、gRPC，大约两三年就进入中立治理阶段。MCP 也是如此，我记得就在最近，Anthropic 刚刚把 MCP 协议捐赠给 AIF，而 OpenAI、Google、微软都是其成员，MCP 从首次发布到现在不过一年左右。

在当前的技术环境下，各大厂商都充分认识到：拥抱开源、共同建设生态、避免协议战争，才能为开发者和企业提供稳定预期，让大家可以放心基于 MCP 生态构建系统，而不必担心被某个厂商锁定。

吴昊宇：各大厂对 MCP 的支持力度非常大，尽管它诞生仅一年，但已展现出强大的优势，几乎所有厂商都已接入，基本成为多 Agent 沟通的事实标准。此外，Anthropic 在 MCP 之上也推出了许多新玩法。例如标准的 MCP 需要逐次调用并等待回复，而 Anthropic 最近的 PDC 协议则通过代码方式将多次 MCP 调用合并为一次。我们的测试结果，与 Anthropic 的官方结论一致：这种方式可使上下文长度缩短 80% 甚至更多。

因此，即便底层协议统一，上层生态仍会不断创新，尤其在大模型时代，可能出现许多此前从未见过的新协议和新生态。如果底层协议稳定可靠，上层生态的创新空间就更大。对于做应用的厂商而言，基于协议探索新的能力和玩法，不仅是机会，也能帮助我们更好地服务企业与用户。

围绕 Agent 架构层层解剖

马可薇：鲁总，企业落地 Agent 最大的拦路虎往往是成本。Agent 的运行模式决定了它需要维护极长的上下文，这对显存和带宽的消耗是巨大的。在大装置层面，你们有没有针对 Agent 这种“长程推理任务”的专用优化方案？

鲁琲：随着 Agent 单任务运行时长不断延长，上下文会出现明显的膨胀，这不仅影响性能，也显著增加成本。为解决长程推理中的上下文问题，目前有多种方法。最基础的是上下文压缩，包括摘要、结构化压缩等；另一类是长期记忆的持久化，即将高价值、高信息量的内容保存在外部存储，如 Vector DB 或知识图谱，以实现高价值信息在跨 Session 之间的传递。这些都属于“上下文工程”的范畴，本质上都是提升信息密度的有效手段。

此外，我们也会对 KV Cache 做优化。例如利用 CPU 内存甚至 SSD 进行分层存储，以提升系统吞吐量；同时可对 KV Cache 进行不同层级的量化。不过，这类方案都会带来精度损失，因为 GPU 中存储的 KV Cache 不是完整版本，在进行前段推理时难免丢失部分信息。根据我们的测试，精度损失大约在 1% 到 10% 之间，具体取决于缓存和同步策略。不同的业务对精度的要求不同，可以选择相应的优化方案，以支持长程、高效、高吞吐的推理过程。

马可薇：王总，作为买单方，如果商汤告诉您“降低一点精度能便宜 50%”，但在导购推荐时可能会偶尔算错价格，值得买的业务容忍度在哪里？

王云峰：每个业务都由多种组件组成，其中一些适合使用 AI 解决，另一些则并不适合。举例来说，若某项能力精度下降 50%，但成本降低 50%，如果这意味着价格计算可能出现错误，那这种情况在业务上往往是无法接受的。相反，有些任务则完全没有必要依赖大模型解决。例如常被讨论的“3.9 和 3.11 到底谁大”的梗，在实际业务中这种计算完全可以由传统方法处理，不必依赖大模型。因此，成本与精度的权衡必须与业务深度结合。我们内部使用了大量模型以及外部 API，不同参数规模、不同价格的模型都会用，关键是把合适的模型放在合适的任务中。

在一些高容忍度的业务场景中，前期并不需要极高精度，因为在海量数据下，整体系统的容错能力非常强。例如舆情分析，其统计特性使得局部精度的误差并不会带来实质影响。但在某些场景下，一点错误也不允许，因此对精度的要求极高。企业必须结合自身特点和业务需求：若天然容错度高，可以使用低成本、精度略低的模型；如容错度低，则必须使用更高精度的方案。最终企业要算整体成本，使整体投入与产出合理。

马可薇：Agent 需要外挂知识库。现在模型窗口越来越大，很多人说直接把书扔进去就行。但对于需要“精准执行”的 Agent 来说，知识图谱（KG）的结构化优势是否比长文本（Long Context）更适合作为 Agent 的“长期记忆”？为什么？

吴昊宇：知识图谱天然具备知识压缩、事实边界与操作约束等特性，因为它由企业大量事实性文档中高频出现的关系和约束构成，再经过专家校验，因此其中存储的内容本质上是企业知识的高度浓缩。当我们以结构化方式将这些浓缩知识提供给大模型时，其约束和提示效果远强于输入冗长且价值不高的文本。其次，知识图谱具有持久性，可以长期存储在图谱库中，根据上下文需求进行调取。在长期记忆方面，它比一次性塞入的大段文本更加稳定、有效。

企业知识库常用的 RAG，本质上还是长文本检索，但它有几个明显问题。第一，由于依赖相关性检索，若关键知识被埋在长文本内部，整体相似度反而可能不如一些不太相关的文本片段，导致真正有用的内容无法被检索到。第二，因为受限于上下文窗口的长度，我们不可能把检索到的 10 段文本全部输入，通常要经过人工筛选或重排序，但这会带来信息覆盖不全面的问题。

相较之下，知识图谱更能保证信息的完整与高度相关。查询一个实体时，其所有相关内容都能被提取，再进行过滤后输入模型，得到的上下文质量显著高于 RAG。此外，我们在许多 deep search 场景中测试，基于知识图谱的 Agent 表现也比 RAG 更优，且生成所需的上下文更短、效率更高。

王云峰：人在处理复杂任务时，最近的记忆细节更丰富，但远期记忆往往只保留关键内容。这种机制其实与知识图谱很相似，都强调保留高价值的信息、过滤无用细节。

在企业中，数据对结果的影响往往大于模型本身。我们常常要面对大量原始数据，其中不少未经结构化处理，也缺乏版本管理。有时同一知识点已被更新，但旧数据无人维护却仍然被输入模型，导致混乱。因此，大量预处理工作十分必要，而知识图谱就是一种极具代表性的结构化方式。它能提升信息密度、利用率，并且便于模型调用。

鲁琲：我们主要用图谱来支持 Agent 的长期记忆，并且让 Agent 能进行一定程度的自我进化。知识图谱是结构化数据，非常符合人类记忆模式，很多事件的细节会随时间遗忘，但关键步骤和方法会被保留，而下一次遇到类似任务时，人会依赖这些高层经验更快解决问题。

我们的一些 Agent 负责线上集群运维，例如 debug 真实故障。最开始它们可能需要反复试错、循环许多轮才能找到解决路径。成功经验随后会写入知识图谱作为长期记忆，并经过一定的反思。当再次遇到类似问题时，Agent 会优先检索图谱，看之前是否成功处理过，从而复用最佳方案。我们看到相同任务从需要 20 分钟逐渐缩短到仅需 5 分钟，这就是长期记忆带来的效率跃迁。

马可薇：鲁总，从算力角度看，是“暴力增加上下文长度”（让模型自己找）更划算，还是“外挂一个知识图谱检索”更划算？

鲁琲：把整本书塞进 context window 与从知识图谱中精准取回高信息密度的节点，两者的算力差距是成百上千倍的，这个账非常好算。

王云峰：千万别动不动就扔长文本。

鲁琲：许多模型在长文本中间部分存在遗忘问题，大海捞针本身就是不现实的任务。尽管大家都宣称拥有超长 context window，但真正有效的部分其实没有那么多。

王云峰：以前没别的办法，大家只能塞文本。现在如果还在往里扔长文本，某种意义上是在“为难模型”，甚至是在刻意找模型的短板。既然有更高效的方式，就应该让模型发挥长处，而不是持续增加它的负担。

观众：企业想要 AI，但不知道如何落地以及不确定投入产出，该从哪一些维度去做决策？

鲁琲：对于具有长期性质的 AI 落地项目而言，大家此时关注的并不是投入产出比，而是项目是否真正能做成。以行业中常见的视角来看，目前能够实实在在为企业赋能的，是那些已经被大规模使用的 AI 应用，比如 AI Coding。现在大型厂商，如微软和谷歌，从去年开始就强制要求员工使用 AI 生成一定比例的代码。如果大厂都在推行这种工作流程，那么企业跟进后带来的效率提升几乎是确定的，性价比也是正向的。至于那些更长期的项目，我认为干脆不必谈性价比，能真正落地就已经非常不错了。

王云峰：AI 的价值主要体现在两个方面：一是提效，也就是原本由人完成的工作转由 AI 处理，并且效率更高；二是 enable something，即让过去在没有 AI 时无法实现的事情变得可能。关于提效，当前 AI 在许多场景中基本可以达到初级到中级人员的能力水平。

如果某项工作具有较高频次、规则性强、同时容错率允许，那么交给 AI 来做效率往往显著更高。而在一些强调创意性的工作中，AI 也表现突出。至少从我们观察到的发展历程看，AI 最初被大量应用的就是创意类任务，比如生成视觉作品，这类任务中 AI 的多样性优势非常明显。

相比之下，编程反而比早期的绘图类任务更晚成熟，因为编程对结果准确性要求更高。不过编程也有其优势：程序本身规律性强、历史代码库丰富，因此模型能够较快适应。相反，对于那些既要求极高准确性，又缺乏明显规律性的任务，AI 目前仍难以胜任。

现在前两类任务 AI 已经能处理得比较好。但如果我们追求 enable something，即实现过去无法做到的事，那么此时无需过多考虑成本，只要在可承受范围内即可。因为一旦能开拓出全新的领域，其性价比可以说是无限大。

吴昊宇：第一个问题是：业务方能否明确说明 AI 的衡量标准？也就是效果好坏需要有客观评估，而不是凭拍脑袋判断。第二个问题是：业务方是否掌握数据？如果没有数据，只能完全依赖大模型从零推断，往往难以取得理想结果；但如果业务方有数据，可以用于提示或微调，AI 的效果通常会更好。还有一点是业务方是否有预算。不能既不给资源又要求结果。如果同学们正在推进类似项目，可以用这几条先和业务方对照一下：他们想实现什么目标？希望达到什么效果？是否有数据积累？如果完全一无所有，或许换个方向会更合适。

马可薇：王总，您之前的分享提到了 MCP Server。在实战中，让通用大模型通过 MCP 协议去调用值得买复杂的电商接口（查价、领券），最难解决的“协议对齐”问题是什么？ 如何防止 Agent 因为“误解”协议参数而乱操作？

王云峰：真正最难的不是协议对齐，而是业务对齐。起初确实会遇到一些协议层面的参数不一致等问题，但从技术角度看，这些都是可解的。有时通过调整模型，或者增加一轮反思，理解用户意图后，再结合传统方法与模型能力，大多能解决协议层面的对齐。真正困难的是业务层面的对齐。虽然协议提供了共同语言，但即便使用同一种语言，相同的词在不同语境下表达的含义也不同。比如“好”或“优惠”等词，在不同业务场景中有不同的业务语义。因此，我们在实践中踩过的坑，往往集中在如何与合作伙伴在业务理解上达成一致。

接下来要考虑的是，这种业务预期是否应该由我们现有接口提供，还是需要新增接口。同时，我们的合作伙伴数量众多，他们各自有自己的设计与呈现方式，而我们需要保持服务的相对标准化，不可能为每家都做定制化。因此真正的难点是业务模型与技术模型如何统一、如何对齐。纯技术层面的参数对齐反而是最不需要担心的，毕竟大家都是写程序的。

吴昊宇：这让我想到 text-to-SQL 的场景。老板问问题时从不会按照模型需要的方式来问，他只会说：“今年业绩怎么样？”这背后对应的是一大堆图表。

马可薇：是的，仍然需要把自然语言或老板的需求转化成机器能理解的表达方式。

王云峰：大模型带来的真正挑战，对技术人员来说，是角色要求的变化。以前很多专业难题需要技术人员凭专业能力解决，现在模型提高了效率，也补足了短板。但这同时带来一个误区，让一些人认为 AI 无所不能，把它当作许愿池。真正的挑战是我们这些技术人员是否能向前迈一步，不仅掌握技术，还要理解业务需求，理解业务语言。大模型虽能理解自然语言，但不一定理解业务语言。

吴昊宇：业务语言需要大量“翻译”。

王云峰：这也是未来 AI 普及后，对程序员、工程师和架构师的真正挑战。

鲁琲：随着 Agent 能力增强，我们常举例，现在让一个 Agent 做图表，工程师能轻松实现。但如果未来企业内部有大量 Agent 参与工作，你告诉 Agent 说：“我给你设一个目标：明年一季度增长 25%。”它该如何实现？这种业务语言的对齐确实很难。

马可薇：吴总，在处理政企复杂流程时，您觉得这种“调度逻辑”是应该写死在代码里（SOP），还是应该让大模型自己去“动态规划”？

吴昊宇：两种方式以及中间状态都可能需要。在要求特别高的领域，例如大型企业，或者老板偏好确定性结果的场景，可以使用 SOP 的方式写死，或采用 workflow 方法，确保可用性和正确性。

在更动态的场景下，可以充分发挥模型能力，比如调研、动态执行等场景。我们现在常用 Claude Code 的 skill 机制，通过约束把技能中的核心流程固定下来，而外围处理交由模型自主完成。这样既有 SOP，又能保留灵活性。

举个例子：我们的一位 HR 想做员工能力评估模型，他给了我们一份咨询报告，希望提炼成能力模型。我们使用“提炼技能”的能力，把文档总结成一个能力模型技能，再将员工的邮件、绩效记录及其他非结构化数据输入，模型就能按技能中的 SOP 自动总结。这样 HR 在几分钟内就获得了一个强大的技能。这个方式能很好地平衡 SOP 与灵活性。在舆情分析等场景也是类似，不同分析师的数据来源和路径不同，但分析框架是一致的，而技能机制可保持这种一致性与灵活性。

马可薇：那现在主流是两种方式混合使用，还是更倾向代码写死或模型动态规划？

吴昊宇：仍然取决于具体场景。如果业务方要求严格，那我们会采用 workflow 的方式处理，虽然现在基本不再直接写代码。

观众：可信 Agent 目前是主要靠 RAG 和知识图谱吗？有没有其他方式？

王云峰：我认为目前如果完全依赖模型，幻觉问题在一些场景下是不可避免的。根据已有研究，在加入 RAG 后，幻觉可以被有效抑制，虽然无法降到零，但确实是目前较好的解决方案。不过，幻觉问题目前没有 100% 彻底解决的办法。如果业务场景要求完全无幻觉，仍需要依靠额外的外围机制或校验流程来确保结果的可靠性，而这也取决于具体的应用场景。

马可薇：当成千上万个 Agent 同时跑起来，这就不是单卡训练的问题了。鲁总，面对这种碎片化推理请求，异构集群（国产 / 英伟达混用）怎么保证调度不卡顿？

鲁琲：调度本质上是推理过程，调度算法需要实时感知推理节点的负载情况，再进行 workload 分发。在同构集群中，判断节点负载已相当复杂，需要综合考虑 GPU 利用率、队列长度、内存占用、以及新任务可能生成的 Token 数等因素；而在异构集群中，这些问题会被进一步放大。同一请求落在不同类型的节点（如国产芯片与英伟达芯片）时，其真实计算消耗往往不同，原因包括算子优化差异、内存访问模式差异、精度差异，甚至节点之间通信方式（NVLink 或 RoCE）的差别。不同设备之间很难完全对齐，因此在实际落地中通常会根据不同卡的压测结果，调整负载评估逻辑并设置不同的权重。

最终通常采用多种调度策略组合，根据不同 workload 的 SLA 要求进行分配。例如，对响应速度要求极高的请求，会优先调度到性能强、负载低的节点；对要求较低的请求，用来做整体负载均衡；而离线推理或批处理任务，会被安排到功耗更低、速度相对慢的设备上。这样可以在保证高 SLA 请求优先满足的同时，让低 SLA 请求提高集群整体利用率，从而形成一套兼顾性能与性价比的组合式调度策略。

马可薇：吴总，在算法层面，如何设计调度策略，是优先保 Agent 的响应速度，还是保系统的整体吞吐量？

吴昊宇：在我们大规模的 Agent 集群中，更关注的是调度链路是否稳定。因为 Agent 的执行过程通常包含规划、工具调用、反思等多轮循环，实际的性能瓶颈往往不在 GPU 或大模型本身，而是在外部异步任务或外部调用时产生大量耗时。因此，我们优化的重点是确保 Agent 能顺畅执行。

这些 Agent 也有不同类型：部分用于实时交互，部分处理异步任务，还有部分负责大批量任务，如处理海量帖子或抓取网页。调度策略必须确保实时交互不卡顿，同时离线任务能充分利用外部资源。我们采用多 Agent、多模型尺寸的结构，让简单任务使用成本较低的小模型，复杂任务使用更强但更耗资源的大模型。通过这种组合优化，可以提升整体并发数，并保持较低时延。

马可薇：王总，在电商导购场景，延迟的“生死线”是多少毫秒？超过多少毫秒用户就会关闭页面？”

王云峰：在 C 端场景中，尤其是对话类场景，1 秒内若不能输出首 token，体验基本就失败了。虽然大家对大模型的容忍度比传统应用高，因为用户已经习惯稍等片刻再看到结果，但总体上仍需在 1–2 秒内给出首 token，并保持持续输出。对于简单问答类场景，几秒内完成输出较为理想；若是深度思考类任务，用户还能接受更长的等待时间。而对离线处理来说，关注的重点变成吞吐量，时延并不那么关键，因此调度策略会根据不同任务类型采取不同侧重。

马可薇：企业用 Agent 最怕它“死循环”或“胡说八道”。在你们的架构中，哪里是那个“红色按钮”（熔断机制）？在应用层，MCP Server 有没有设计业务逻辑上的“熔断机制”？在基础设施层，有没有资源消耗上的“硬熔断”？

王云峰：一般来说，我们会设置一个循环阈值，超过后即可认定系统已出现崩溃，这是最基础的做法。对于对外提供的 MCP Server，由于全部是预处理好的数据，因此通常不会出现死循环的问题，但我们会对吞吐做一定的熔断和限制。整体机制与传统系统中的熔断并无本质区别。

鲁琲：我们的熔断机制更多是在技术架构层面，在基础设施层面通常会为每个 Agent 分配独立的 API key，并对各 API key 设置 rate limit 和预算上限。即使 Agent 进入死循环，在 Token 消耗超限后也能被限制住。MCP Server 也是类似逻辑：为了防止 Agent 死循环，需要在 API 层面设置 rate limit。整个系统的构建都基于“互相不完全信任”，因此必须做各种层次的防御。

吴昊宇：我们的 Agent 基础设施，主要通过沙盒机制实现隔离。Agent 的执行环境运行在独立的虚拟机中，即使出现循环、资源耗尽或挂掉的情况，也不会影响外部的主控系统。其次，我们会监控 Agent 的执行状态，包括是否循环、资源占用是否异常、是否频繁发送请求等，并通过网络、硬盘、CPU、内存等维度进行监控。如果判断运行异常，会在外部直接将其 kill 掉。

此外，在 Agent 执行过程中，人工可以随时中断其运行，通过外部协作判断 Agent 是否正常。面向企业场景时，我们还需对模型及其任务规划、执行模型进行调整，确保规划路径和执行动作符合可信标准，避免生成过于离谱的操作，并在执行中加入必要的安全检查，防止触发高危操作。

展望 Agent 的未来形态

马可薇：如果 Agent 成为主流，未来的软件（ERP/CRM）会不会消失，只剩下 API？作为技术人，我们现在是应该去学“怎么写 Agent”，还是去学“怎么写被 Agent 调用的 API”？

鲁琲：我相信在非常长远的未来，软件形态本身会消失。但在这一未来到来之前，在相当长的一段时间里，软件的核心功能仍将被保留，而其中与人交互的部分会逐渐淡出，由类似 Agent 的交互模式取而代之。在这种模式下，Agent 事实上承担了软件外壳的作用。软件的核心功能会以 API 的形式暴露给 Agent。

对初级开发者而言，仍需通过扎实学习掌握复杂的后端 API 开发和业务核心功能，并逐渐形成对系统架构和高并发系统的深入理解。而对中高级开发者来说，在具备 API 层面的深刻认知后，可以进一步尝试 Agent 的开发，更好地弥合 AI 应用与后端服务之间的 gap。我认为这类具备双向能力的人，未来会在市场上变得非常稀缺。

吴昊宇：未来可能真的不再存在传统意义上的软件界面，UI 可能完全消失，取而代之的是由 Agent 与系统直接交互。当然，软件本身仍可能以 API 形式存在，因为构建完整系统仍需专业软件厂商去完成，只是 UI 不再由人直接使用，而由 Agent 处理。企业内部甚至可能形成一个“超级 Agent”，管理几乎所有业务流程。

基于此，即便技术人员没有从事 Agent 开发，我仍建议大家理解 Agent 的工作原理，包括它如何运作、如何被调度、运行基础是什么，以及 Agent 之间如何交互。至于 API 的学习需求，则取决于各自的工作方向。面对高并发场景或后端基础能力的建设，相关技能依旧必不可少。幸运的是，现在比过去有了更好的学习条件，AI 能帮助理解架构、编写代码和传授经验，对技术人员而言是非常好的时代。

王云峰：Agent 之所以强大，是因为它站在“巨人”的肩膀上，而这些巨人就是历史上无数程序员一行行写出的代码。二十五年前，会写 HTML 都是非常重要的技能，写页面的人收入甚至比写 C++ 编译器的人还高；但市场很快变化了，因为这些技能极易被新工具替代。

现阶段，会使用 AI、会搭建一个 Agent 是一种偏表层的能力，而更核心的依然是对计算机整体运行机制的理解。我不知道量子计算机何时普及，但至少目前 Agent 的上层表现再“神奇”，底层仍是基于最基本的数学和计算机原理，在冯·诺依曼体系结构上运行。因此，如果希望避免被时代淘汰，就必须知其然并知其所以然。

很多依赖记忆或机械性劳动的工作未来会被 Agent 覆盖，但真正理解底层原理的能力，才能帮助我们把握 AI 的能力边界，识别它的长板与短板，并更有效地利用它。因此，计算机最基础的知识永远有价值。你可能不会显式意识到自己在使用这些知识，但它们形成的思维习惯与直觉，会成为你使用 AI 能力的重要底层支撑。

马可薇：在 Agent Infrastructure（基建）领域，2026 年最可能爆发的一个技术变量是什么？

鲁琲：我认为未来应当形成多 Agent 的治理体系。2025 年 Agent 的发展非常迅速，从早期的 demo 已经逐渐落地到生产环境，并出现了许多现象级的 ToC 应用，如 Manus。到 2026 年，我相信 Agent 将被更多企业级应用采用，逐步成为企业运行基础设施的重要组成部分。

生产级的多 Agent 落地很可能在 2026 年大规模发生。从技术角度看，多 Agent 之间的交互协议基础已经初步具备。然而，单 Agent 的运维、调试、性能监控与迭代本身就极为复杂；当系统扩展到多 Agent 后，这些复杂性将呈指数增长，多 Agent 的交互逻辑会隐藏大量潜在问题，一个 Agent 的异常输出可能污染整个系统的上下文，甚至导致系统性失败。因此，构建完善的多 Agent 治理体系，是企业级落地的必要前提。

吴昊宇：Agent 体系确实是非常重要的发展方向。目前常见的 Claude Code 以及我们公司自研的一些 Agent 框架，实际上都在探索多 Agent，只是距离成熟还很远。我们关注的核心问题是：如何让企业敢在真实生产环境中使用 Agent？关键在于让 Agent 的产出结果具备可信性。

我们主要从两个层面提升可信性。第一是数据可信，即数据源是否真实、有效，并通过知识图谱等方式增强上下文的可靠性，避免 Agent 在执行过程中偏离核心语义。第二是模型输出可信，即从任务规划到任务执行的整个链路都要可控、可靠，确保规划合理、执行安全，不产生危险操作，并能准确落实意图。

王云峰：从技术层面看，不确定性仍然很多，算法和算力的发展方向也未必有明确答案。但我认为最关键、也最希望发生的事情并不在技术本身，而在市场端：希望在 2026 年，市场对 Agent 的认可度能够显著提高。

AI 是一种彻底的颠覆性技术，与以往技术不同，它在很多方面甚至需要整个市场被重新教育。在人们没有形成足够理解之前，很难发挥其全部能力。尤其在企业场景下，对安全性、数据与结果准确性都有更高要求。如果仍停留在“要么把它当万能许愿池，要么认为一无是处”的极端认知，那 Agent 很难发挥作用。

我们期望有越来越多的用户和企业找到适合自身业务的 Agent 使用方式，发挥其长板、规避其短板，使 Agent 真正为业务创造价值。今年我们一直在讲“Agent 元年”，而一个行业之所以能持续有人投入研究与建设，最终仍需要在市场中产生真实成效。

本文来自微信公众号“InfoQ”（ID：infoqchina），作者：李忠良，编辑：宇琪 ，36氪经授权发布。