企业Agent可信度提升：技术架构、挑战与未来展望

随着AI技术从工具化向自主化演进，智能体（Agent）正成为企业应用大模型的关键形态。那么，如何优化Agent，使其更可信、更好用，最终蜕变为企业优秀的“数字员工”？

近日，InfoQ《极客有约》与AICon直播栏目特邀RBC高级应用支持分析师马可薇担任主持人，携手值得买科技CTO王云峰、商汤科技大装置事业群高级技术总监鲁琲、明略科技集团高级技术总监吴昊宇，在AICon全球人工智能开发与应用大会2025北京站前夕，共同探讨如何提升企业Agent的“可信度”。

部分精彩观点如下：

• 未来传统软件界面可能消失，UI或被Agent与系统的直接交互取代。
• 协议的价值在于让生态中的各方（提供大脑、数据、工具或执行能力的厂商）使用同一种语言沟通，专注专业领域，避免适配消耗。
• 许多模型在长文本中段存在遗忘问题，大海捞针本不现实；尽管超长上下文窗口被宣传，但有效部分有限。
• 真正的难点是业务模型与技术模型的统一对齐；纯技术参数对齐反而简单，毕竟程序员都懂代码。

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

定义Agent的技术边界

马可薇：许多人觉得Agent只是Chatbot加插件。但从技术架构看，当系统目标从“对话”转向“行动”，您认为技术栈上最大的质变是什么？

王云峰：Chatbot仅是交互形态。过去互联网依赖点击，后AI具备对话能力，用户开始在对话框中交互；端到端语音和多模态使对话更自然；Agent则扩展了可操作范围。Chatbot是界面，关键逻辑在于背后大模型。我们常把大模型比作“大脑”，传统Chatbot只是让用户简单交互压榨知识。但聪明大脑需要外围系统，如人的感官和手脚，以感知世界、执行操作。完整过程包括：模型接收任务、判断行动、感知外界、接收反馈并调整规划。这与单纯Chatbot模式差异巨大，技术复杂度和生态要求远高于对话系统。

鲁琲：以对话为目的的AI重过程，以行动为目的的AI重结果。回想GitHub Copilot初期，只有代码补全，本质是Chatbot。流程是：模型补全代码，若不理想，程序员反馈请其修改；代码报错后再贴回修改，循环至成功。Agent模式自动化了这套流程：先前规划由人完成，需脑中维护任务步骤和上下文切换；Agent将其纳入系统，自行规划、调用工具、管理上下文。核心在于模型增强了记忆和上下文管理能力，将人的短期、中期、长期记忆和状态转移至Agent内部。因此，Agent能在循环中持续工作数十分钟甚至数天，始终知晓已做、正做和将做之事，这体现了技术栈的重大质变。

吴昊宇：这与豆包手机爆火相关。豆包与努比亚联合推出的手机可由AI直接操控，但随后微信、淘宝等平台禁止登录。体验后确实强大，它不再是对话形态，而是能按指令在手机上逐步操作。这意味着AI具备了任务规划和执行能力，在企业场景同样重要。例如，让AI判断话题热度，它不应简单搜索回答，而需规划整套步骤：检索、汇集相关词帖、情绪聚类、生成报告等。与过去问答或简单文本分析完全不同，对规划与调度能力要求显著提高。其次，系统具备“动手”能力后，权限与责任扩大。AI可访问手机相册、聊天记录；在企业内部可能访问工作软件、数据库。系统必须具备可追溯、可干预能力，并设安全边界，否则行为不可控。因此，Agent架构中加入大量监控、可验证机制及人工闭环控制，这也是与Chatbot模式的最大差异之一。

马可薇：当前Agent常“变笨”或“卡住”。从算力供给、数据供给、协议交互看，目前的“短板”在哪个环节？是推理速度慢、上下文记忆短还是其他？

鲁琲：更准确说是高性价比算力短缺。实际落地中，问题常在于成本与效果权衡。许多应用场景不使用旗舰模型，而选30B甚至7B小模型。尽管这些模型支持100K或200K上下文窗口，实际使用仍限32K或更小，以降低成本。同样，我们限制Agent深度思考轮次，如在Cursor中开启Max模式，用最佳模型生成功能，执行二十分钟可能耗尽当月配额。若有更多高性价比算力，顶尖模型与算法才能在更广场景发挥能力。

吴昊宇：上下文数据质量也至关重要。即使上下文长，若信息质量低、噪声多，模型输出的任务规划和结果仍不理想。像舆情分析常用小红书、微博帖子，但信息密度低。若将一万条帖子直接丢给大模型总结，所得观点和事实可能不完整或有偏差。因此，我们常预处理数据，再交模型生成总结或报告。此外，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元年”，而一个行业之所以能持续有人投入研究与建设，最终仍需要在市场中产生真实成效。