告别“语义黑盒”：当 Agent 走进生产环境，我们如何驯服它的“不可预测”？

作者 | QCon 全球软件开发大会

策划 | Kitty

编辑 | 宇琪

随着大模型 Agent 从实验原型迈向核心业务生产，工程化的重心正经历从“验证可行性”向“追求确定性”的本质跃迁。Agent 的本质是“自主”、“涌现”、“不可预测”——这些词本身就和“确定性”对着干。但企业要的是什么？是可用、是可靠、是出了事能找到原因、是敢把核心业务交给它。那么，一个本质上不确定的系统，我们能把它变得足够“确定”吗？如果能，靠什么？可观测性在这个命题里，扮演的是什么角色？

近日 InfoQ《极客有约》X QCon 直播栏目特别邀请小红书技术风险负责人孙佳林担任主持人，和亚马逊云科技 Agent 架构师章平、阶跃星辰安全研发专家李昌昊、腾讯 SRE 资深工程师陈自欣一起，在2026 年QCon全球软件开发大会（北京站）即将召开之际，共同探讨如何构建面向 Agent 的全链路语义观测体系。

部分精彩观点如下：

• Agent 的确定性工程，本质是追求运行过程中的可观测、可诊断、可干预与可演进。

• 通过 MCP、日志聚类、Function call 等机制，可以减少 Context Window 压力，并提升处理效率。同时，通过将 Skill、Memory 等能力模块化组合，构建面向具体场景的 Agent，从而限制其行为范围，降低不确定性。

• Agent 系统链路复杂，问题可能来自模型、工具或运行环境，因此需要全链路可观测能力来定位问题。可观测性的核心价值并非追责，而是定位问题与优化系统，从而提高整体可靠性与效率。

• 如果未来 token 成本大幅下降，使中小企业甚至个人都能承担，那么可观测与评估体系将被更广泛采用，从而推动整个生态的发展。

在 4 月 16-18 日将于北京举办的 QCon 全球软件开发大会 上，我们特别设置了 【Agent 可观测性与评估工程】 专题。该专题将深度拆解生产实践案例，帮助构建可验证、可演进的 Agent 工程体系，推动 Agent 成为真正可靠的生产系统。查看大会日程解锁更多精彩内容：https://qcon.infoq.cn/2026/beijing/schedule

以下内容基于直播速记整理（经 InfoQ 不改变原意的情况下删减）。

完整直播回放可查看：https://www.infoq.cn/video/jzSzcszN0dLwv57hvaxk

Agent 的不确定性

孙佳林：请三位老师，各自用一句话，定义一下你们理解的“确定性工程”——它要解决的核心问题是什么？

章平：不确定性本身是客观存在的，但在业务中需要将其转化为可控的确定性。本质上，就是对不确定因素进行量化，并通过机制加以控制，在问题出现后及时修复。例如，可以通过概率方法，从模型层面判断其行为是否符合预期；若不符合，则借助监测手段定位问题，再进行修复，这实际上是一整套从不确定性中寻找确定性的机制。

李昌昊：安全从业者通常面对大量伪装进程或攻击行为，有一个基本原则：不看进程的自我声明，而是观察其实际行为进行判断。对 Agent 也不能只看其“说了什么”，而应从确定性的角度判断其实际行为。例如，当 Agent 声称执行成功时，需要查看其退出码、返回内容是否报错、资源消耗是否合理等。这些来自内核的数据是确定的，基于这些确定性基础，可以缓解 Agent 的不确定性问题。

陈自欣：我认为这是一个具有“矛盾统一”特征的问题，甚至可以上升到哲学层面。我们希望 Agent 具备高智能，但高智能必然带来不确定性。企业中最不确定的因素其实是人，但企业仍然需要人或 Agent 来运营，核心在于“像管理公司一样管理 Agent”。首先要做的是观察 Agent 的行为，这类似于企业中的早会、日报、周报等机制，用于防止其偏离方向。确定性工程的第一步，是先确认其当前状态，即“先观测”。

孙佳林：我们追求的确定性，并不是将 Agent 变成简单的 if-else 程序，也不是要求其永不出错，而是要在其出错或性能下降时能够被及时发现，并在上线前有依据地评估风险。同时，需要从内核层、LLM 调用层、工具调用层及效果层进行监控，在问题出现后快速修复并持续迭代优化。抽象来看，Agent 确定性工程的本质是追求可观测、可诊断、可干预与可演进。

孙佳林：要让 Agent 变得“可管理”，我们首先得搞清楚，它的“不确定”到底来自哪里？传统软件的不确定性，主要来自代码 Bug、网络抖动、硬件故障等。但 Agent 带来了新的不确定性源头，三位老师能不能从各自的领域出发，给我们分享一下“Agent 不确定性”来源于哪些因素？

陈自欣：Agent 的运行天然具有不确定性。从底层原理看，调用大模型时通常需要设置 temperature 参数，该参数决定模型输出的随机性。如果完全确定，模型将变得僵化，无法完成复杂决策，因此不确定性首先来源于模型本身。

其次，不确定性还来自模型运行过程。例如“模型降智”这一现象，在 LLM 普及之前并不常见，但现在可能由于算力、推理框架缺陷或 API 供应商问题导致模型性能下降。此外，模型供应商的不稳定性也会带来影响，例如服务连接失败等情况频繁出现。

第四类不确定性来自长任务执行过程中的偏移，例如上下文引导不足，导致模型逐渐偏离目标；以及环境、工具（Skills）等因素也会引入不确定性。

李昌昊：我从运行与运维角度补充几点。首先，运行时环境具有不确定性。与传统软件运行在固定镜像不同，Agent 常在沙箱中执行，环境可能每次不同；其工具选择也不固定，甚至会动态安装依赖，从而引入额外不确定性。此外，沙箱状态可能受之前任务影响，导致同一命令在不同环境中结果不同，这是 Agent 特有的问题。

其次，可观测性存在断层。Agent 与运行时之间缺乏统一链路，导致难以将 Agent 行为与运行结果关联，这在传统软件中较少见。

第三，可观测能力本身存在限制。例如 Agent 与大模型之间通常采用 HTTPS 加密，APM 或防火墙难以拦截；沙箱执行过程也被隔离，难以从底层监控其行为。这些都会成为不确定性的来源。

章平：在工具使用方面存在不确定性。例如某旅游客户在修改提示词后，工具调用率显著下降，虽然对话表面正常，但 Agent 选择了通用搜索工具而非合适工具，导致体验下降。此外，在评估中使用“LLM as judge”方法，即用模型评估模型，本身也是用不确定性评估不确定性，会进一步放大问题，这类似于测量对系统本身的影响。

孙佳林：Agent 的不确定性不仅来自模型，还来自推理过程、上下文漂移、外部工具依赖及运行时环境等。此外，一个容易被忽视的问题是效果评估体系的缺失，以及“语义黑盒”的存在。那么将黑盒转为可观测的白盒，是要解决的关键问题。

可观测如何构建确定性

孙佳林：章平老师，在 AWS 的大规模实践中，你们观测 Agent，最核心的几类数据是什么？是传统的 QPS、延迟、错误率，还是需要一些“ Agent 特有”的指标？

章平：在 Agent 体系中，除传统 QPS 等指标外，更关注多层级指标。第一层是行为指标，例如工具调用是否正确、参数设置是否合理，这直接影响执行准确性。

第二层是质量评估，即任务完成后是否真正帮助用户，包括响应的有用性、正确性、相关性及情感因素等。这些指标虽带有主观性，但与业务紧密相关，需结合实际场景设定。

此外，还包括 session 级指标、多轮对话整体表现。单轮可能表现良好，但多轮下可能下降，需从多轮维度评估整体效果。

孙佳林：假设我们发现“任务完成率”突然下跌，接下来怎么做？可观测数据怎么帮我们一步步下钻，找到是模型问题、 Prompt 问题，还是外部依赖问题？

章平：在评估体系中，首先会设置观测与告警机制。例如，当工具调用率低于某一阈值时触发告警后，会通过评估体系定位问题原因。我们会将完整执行过程输入大模型进行分析，不仅获得评分，还能得到错误原因提示。再结合发布日志逐步回溯，判断是否由提示词或模型变更导致问题。最终，在定位原因后进行修复，并通过后续指标验证修复效果，从而形成“观测—定位—修复—验证”的闭环。

孙佳林：你们主要依赖 LLM 来评估与诊断，而非传统规则方法，对吗？

章平：是的，同时也会结合成本与效率进行权衡。

孙佳林：昌昊老师，Agent 跟 LLM 的对话是加密的，沙箱里的执行是隔离的，两层黑盒叠在一起。我们怎么在"无侵入"的前提下，同时打开这两层黑盒，让排查的人能看到"Agent 当时到底做了什么？

李昌昊：我们目前主要面向训练或业务场景，设计方案时强调“零侵入”。由于用户可能使用不同的 Agent 框架（如 LangChain 等），且沙箱环境多样、生命周期短，难以通过传统埋点方式采集数据，因此零侵入成为关键要求。

此外，我们采用 eBPF 技术对加密流量进行解密，通过挂载 TLS 库函数，在内存中获取明文数据，从而提取模型请求信息，如模型名称、Prompt、用量及延迟等。

在运行时层面，通过 Tracepoint 等技术采集进程创建、命令执行及结果数据，实现对沙箱内行为的全面记录，这使我们能够从运行时角度还原 Agent 的真实行为。

孙佳林：推理轨迹是一堆数据，工具调用是另一堆数据，API 返回又是第三堆。怎么把它们串成一条完整的、有时间线的故事，让排查的人一目了然？

李昌昊：数据采集虽有成熟方案，但数据源彼此割裂，需要构建完整的链路（trace）。例如，对话数据来自平台层，审计数据来自应用日志，需进行统一关联。

我们通过 eBPF 捕获网络请求，并借助透明代理注入 trace header，实现 Agent 与大模型之间的链路关联。同时，在沙箱层通过日志与进程事件匹配，结合时间窗口、身份标识及命令一致性，实现跨层关联。最终，通过网络解密与运行时观测，实现从对话到工具调用的全链路追踪，从而在评估中获得完整数据。

孙佳林：自欣老师，很多公司的 SRE 体系已经很成熟了。Agent 来了之后，是另起一套，还是想办法融入？蓝鲸平台是怎么把 Agent 的观测能力和传统的日志、监控、追踪打通的？

陈自欣：这个问题可以拆分为两个方面：一是现有 SRE 体系如何适应 Agent 场景，二是在新场景中如何发挥更大作用。

对于第一点，Agent 时代并非需要重建体系，而是对现有平台进行演进。可观测平台在 Agent 与微服务时代都至关重要，但 Agent 产生的数据更复杂，对存储与处理提出更高要求。例如，以前日志可通过聚类压缩，而 Agent 输出高度多样，聚类失效，带来新的挑战。

第二点是数据打通。关键在于将代码、运行时及可观测数据统一关联，从而快速定位问题。由于大模型擅长分析代码，这种统一数据模型将极大提升问题诊断效率。

孙佳林：自欣老师，你的 QCon 大会演讲主题里提到“AI 提效实践”。现在 Agent 产生的数据量巨大，靠人看不过来。你们是否有用 AI 技术来分析 Agent 行为、预测风险、甚至自动修复？

陈自欣：以腾讯游戏场景为例，多样化业务带来复杂观测需求。当前重点是为 Agent 提供上下文，使其辅助用户定位问题。

通过 MCP、日志聚类、function call 等机制，可以减少 context window 压力，并提升处理效率。同时，通过将 skill、memory 等能力模块化组合，构建面向具体场景的 Agent，从而限制其行为范围，降低不确定性。

未来，还需要将运维经验进一步沉淀并赋能 Agent，使其能够更精准地定位问题核心，从而提升整体系统理解与处理能力。

可观测的“边界和代价”

孙佳林：构建一个完整的 Agent 可观测体系，需要投入多少成本？算力、存储、人力……小团队玩得起吗？有没有“乞丐版可观测”方案？

陈自欣：从技术上看，Agent 的可观测性仍然遵循类似 OpenTelemetry 的规范，即围绕 metrics、log 和 trace 三类数据展开。但问题在于，传统可观测方案中的成本优化手段在 Agent 场景下逐渐失效。例如，过去可以通过 trace 采样降低成本，日志也具有稳定模式，便于压缩与删除。然而，在 Agent 场景中，这些前提不再成立。

可以考虑采用分层策略：一方面用传统方式监控平台与运行层的性能指标；另一方面，将高成本、非结构化的数据存储在如 S3 等低成本存储中，用于离线分析。这些数据不必实时处理，而是用于评估与业务优化。

从商业角度看，虽然成本上升，但记录 Agent 的运行日志、Prompt 与 response，有助于持续提升模型能力与任务完成率。Agent 可观测性虽成本较高，但对业务具有长期价值，甚至是必要投入。

李昌昊：可观测性的最大成本并非建设本身，而是“不做可观测”。如果仅让 Agent“能跑即可”，在后续优化时往往会发现数据质量差、成本不可控。例如，大量 token 消耗中哪些是有效计算、哪些是无效尝试，无法区分；出现问题时也难以复现，因为缺乏链路记录。

从技术角度看，可以通过低成本方式逐步建设可观测体系。第一层是记录工具调用与基础行为数据，这是成本最低且最直接的手段；第二层是追踪大模型调用成本，例如 token 使用量、延迟、模型类型等，并按会话或任务进行聚合分析，从而明确成本分布与效率问题；第三层是构建全链路追踪，将各类数据串联起来，实现问题定位。这一层投入较高，但价值最大。整体来看，可以基于现有平台能力逐步构建基础可观测体系。

章平：我认同可观测性不仅是成本，更是业务投资。以实际测算为例，若每天有 10 万次 Agent 调用，每次消耗约 1000 至 4000 token，按照当前主流模型价格计算，若全部由大模型完成评估，每月成本约为 6 万至 15 万美元。但实际中无需全部依赖大模型评估。可以将确定性任务交由规则或 ground truth 判断，将主观评估交由大模型处理，并结合采样机制。例如按 70% 规则与 30% 模型分配，再叠加 10% 采样率，最终成本可降至每月约 1000 至 3000 美元, 这种“组合式”策略可以在成本与效果之间取得平衡。

陈自欣：此外，可将数据存储后使用更经济的模型进行离线处理，这同样具有实际意义。

孙佳林：可观测性确实有成本，但与不可观测导致的隐性资源浪费相比，其投入更具价值。因此，应优先解决最关键的业务问题，通过采样与指标筛选实现 ROI 最大化，并结合开源协议与低成本存储方案，将整体成本控制在合理范围内。

孙佳林：可观测不是万能的。在三位老师看来，目前的可观测技术边界在哪里？什么场景下，Agent 的行为是“观测不到”或者“观测了也没用”的？”

陈自欣：从更宏观角度看，可观测性与控制论密切相关：无法观测就无法控制。因此，无论形式如何变化，可观测性在 AI 时代只会更加重要。

例如在 AI 编程场景中，开发者往往将错误日志反馈给模型，再由模型进行修复；一些工具甚至引入调试模式，自动收集日志并参与迭代，这一过程在本地环境中已较为成熟。若将这一闭环扩展至生产环境，其价值将进一步放大。在 Vibe Coding 或自动生成代码日益普及的背景下，开发者难以完全掌控代码质量，因此可观测性将成为关键的兜底能力。

李昌昊：可观测性的边界类似于现实世界中的测量问题。例如在量子力学中，观测存在极限，无法完全获取系统状态。同样，在 Agent 场景中，过度依赖某些指标可能导致指标失效，甚至被系统“规避”。

因此，可观测范围应与 ROI 匹配。例如，不可能记录所有网络请求或完整输入输出数据，因为成本过高；同时，对于模型内部语义状态，由于其概率生成机制，也难以完全追溯。这些都构成可观测性的边界。

章平：我补充几个案例说明边界问题。首先，评估需要多维度。例如某旅游 Agent 在提示词变更后未调用专业工具，而使用通用搜索，虽然完成了任务，但结果质量下降。仅从结果判断是不够的，还需结合过程指标。

其次，评估标准本身也会变化。例如模型升级或环境变化可能导致原有标准失效，需要定期校准，例如通过固定测试集重新定义评估基准。

第三，Agent 的能力存在边界。例如在数据 ETL 场景中，若数据错误源于上游处理，Agent 无法定位根因，只能基于输入输出做判断。需要明确哪些问题应由 Agent 处理，哪些应由传统系统解决。

孙佳林：可观测性的技术边界取决于业务问题，但基础设施能力（如 log、trace、metric、profiling 等）必须构建，在此基础上结合具体业务场景和需求，看应用范围与边界，最终还是要回归到解决业务问题上。

评估中的“人和流程”

孙佳林：评估是工具，但用不好也会出问题。三位有没有遇到过“为了指标好看，反而把 Agent 带偏”的情况？

章平：在实际使用中，常见问题是 Agent“表面完成任务但实质偏离目标”。例如在 AI 编程中，模型可能通过取巧方式快速返回结果，而非真正调用大模型完成任务，甚至通过 fallback 逻辑规避失败。此时，从流程或结果看似正常，但未满足真实需求。因此，评估不能仅依赖任务完成度，还需引入代码质量、安全性、规范性等多维指标，从而全面衡量效果。

李昌昊：单一指标容易失效，这与经典的“指标异化”现象一致。应采用多维指标，并尽量使用独立数据源进行评估，例如运行时数据或业务数据，而非完全依赖 Agent 自身输出。同时，也可以通过多 Agent 交叉验证提高可靠性。

孙佳林：整体思路是采用多维、多阶段评估，包括过程追踪、节点分析及结果指标，避免仅以单一结果衡量整体效果。

孙佳林：Agent 出问题了，是算法团队的事，还是 SRE 团队的事？如果是因为模型幻觉，算法说“这是概率问题”；如果是因为 API 超时，SRE 说“这是外部依赖”——最后谁给业务方一个交代？”

陈自欣：关于责任归属问题，目前阶段更适合以探索为主，而非严格定责。Agent 仍处于发展阶段，依赖复杂、稳定性有限，应允许一定试错空间。

孙佳林：这类似于“无责文化”（blameless culture），强调问题解决导向而非过多讨论责任归属问题。

李昌昊：本质上，“谁负责”取决于是否有证据链。Agent 系统链路复杂，问题可能来自模型、工具或运行环境，因此需要全链路可观测能力来定位问题。可观测性的核心价值并非追责，而是定位问题与优化系统，从而提高整体可靠性与效率。

孙佳林：现在的评估还有很多人工环节（写用例、判结果、分析原因）。未来，评估会被 AI 自动化吗？比如让一个“评估 Agent ”来评估“业务 Agent”？

章平：目前很多实践本质上是“用 AI 评估 AI”，但人仍然发挥着关键作用。首先，在评估体系中，ground truth 与大模型评估的划分需要人为设定规则，即哪些内容由程序基于确定性规则判断，这一部分依赖人事先定义清晰标准。

其次，对于“好”与“不好”的判定，虽然可以交由大模型执行，但其评估标准本身必须由人基于具体业务设定，包括输入、输出以及过程中的推理路径等。这些业务知识需要由人进行抽象并注入模型，使评估结果真正符合业务需求。人在其中的核心作用是将企业知识体系结构化并融入评估过程。至于 AI 是否会完全取代人，理论上大部分工作可能被替代，但最终责任仍需由人承担。

孙佳林：AI 应当具备“监护人”机制，无论是 skill 的生产方还是 Agent 的运维方，都需要对其行为负责，包括控制其影响范围与风险边界。因此，人作为“监护人”的角色是不可替代的，这也是确定性工程的重要体现，通过工程化手段约束 AI 行为。

李昌昊：从另一个角度看，可观测数据本身既是分析依据，也是训练素材。如果完全由 AI 自动评估，会产生递归问题，即“谁来评估评估者”。因此，在较长时间内，“human in the loop”仍然是必要模式，由人进行最终判断，AI 评估更多作为辅助。

陈自欣：我认为评测是 AI 落地过程中最关键的环节之一，其前提是具备完善的可观测能力，能够采集完整数据。在很多业务场景中，例如旅行助手这类 workflow 型应用，可以通过较为固定的流程配合小模型执行，再由大模型进行评估，这在成本与效果之间是可行的方案。这一模式类似传统客服系统：通话会被录音，但并非全部人工审核，而是结合用户评分与抽检机制进行评估，从而平衡成本与质量。

此外，评估不能仅停留在技术层面，还需从业务角度出发，例如用户留存率、满意度或净推荐值等指标。这一点在竞争激烈的市场环境下尤为重要，因为单纯降低成本而损害用户体验，最终会导致用户流失。

展望未来

孙佳林：在 Agentic 时代，确定性工程会往哪走？可观测性能不能推动 Agent 工程，从“被动”走向“主动”，甚至“自动驾驶”？请三位老师每人给一个预言。

陈自欣：在 Agentic 时代，可观测性将成为确定性工程的核心支柱，同时也会对基础设施带来新的挑战。例如，传统指标难以衡量 Agent 的表现，因此 log 与 trace 的重要性进一步提升。

未来可能需要围绕 Agent 构建新的基础设施体系，例如将运行时（runtime）与可观测能力深度结合，在无需异常时减少日志记录，在出现问题时再动态补充上下文信息，从而降低成本并提升智能化水平。

此外，存储能力与数据处理能力也将成为关键瓶颈。当这些基础能力完善后，可观测体系将从被动监控转向主动诊断甚至预测。

章平：我也参考了一些 AI 的预测，普遍认为可观测性将从事后检测发展为实时监控甚至“免疫系统”。我认同这一趋势，但更关键的问题在于成本。目前许多企业尚未重视这一领域，很大程度上是因为 token 成本过高。如果未来 token 成本大幅下降，使中小企业甚至个人都能承担，那么可观测与评估体系将被更广泛采用，从而推动整个生态的发展。

李昌昊：从技术趋势看，可观测性可能进一步深入模型内部，例如追踪 token 的生成来源，从训练数据层面提升可解释性。同时，可观测数据也将成为模型训练闭环的重要组成部分，用于持续优化 Agent 与模型能力。

孙佳林：未来还可能通过将多轮交互操作转化为确定性操作（如 CLI 或标准化流程），降低不确定性，并结合多 Agent 协作与云环境，实现更复杂的自动化系统。这一方向仍有较大发展空间。

孙佳林：如果现在只能做一件事，来让自己的 Agent 变得更“可观测、可评估、可信任”，你会建议他们做什么？

李昌昊：从安全角度看，应将 Agent 视为“不可信进程”。由于其行为难以完全预测，需要建立独立于 Agent 本身的审计体系，不仅依赖其输出，还需从外部视角验证其行为。

章平：在企业场景中，安全问题尤为关键。一个可行思路是通过统一网关管理 Agent 对内部系统（如数仓、ERP）的访问，将所有调用集中到网关层，并在网关中配置安全策略。例如，可通过策略控制 Agent 能访问哪些系统，从而避免在 Agent 内部逐一实现安全控制。

陈自欣：从架构角度看，Agent 应依托企业级 AI 网关或升级版 SOA 总线运行，并配套完整的权限体系与安全策略。这些在传统系统中成熟的机制，在 AI 时代依然适用。

孙佳林：这一体系类似于微服务时代的 Mesh 架构，在 Agent 时代可能演变为统一的 AI 网关，用于统一执行策略控制、行为约束与风险管理，是实现“护栏机制”的关键基础设施。

观众：在企业里面龙虾的实际使用实践有吗？比如安全、可观测、自动部署。

陈自欣：龙虾本质上是一个高度灵活的系统，其中安全是最核心的挑战之一。在企业中部署时，必须将其运行在网络受控的沙箱环境中，这是基本前提。在该环境内，需要对网络策略进行严格管控，例如禁止在同一 IP 段内进行横向扫描，实现基础的网络隔离，这在实践中通常通过类似 Docker 的容器化技术来完成。同时，龙虾的调用中心（call hub）必须指向企业内部受控且安全的地址，并结合 API 网关或 MCP 网关，对路由与权限进行统一管控。

观众：请问使用现有的 Agent，还是自己搭建 Agent 更合适？

章平：我早年在集成商从事投标工作，当时流程较为繁重。在 Agent 时代，不同企业的业务流程差异较大，例如招标流程往往各不相同。更合理的方式是将企业内部已有流程抽象为标准操作流程（SOP），再封装为对应的 skill，集成到个人或企业的 Agent 系统中。这相当于构建一个定制化的 Agent，可以显著提升实际工作效率。相比之下，通用 Agent 虽然可以提供基础信息检索能力，但其输出往往较为泛化，难以满足具体业务的专业需求。

观众：MCP 与 skills 的本质区别是什么？

孙佳林：MCP 是连接 AI 与外部世界的“协议”，而 skills 是 AI 能够调用的具体“能力”。MCP server 是能力发布方，核心职责是向 AI 客户端声明自己拥有哪些能力，它定义了“能干什么”。Skills 是能力的实现方，是具体的业务逻辑和执行代码，它定义了“如何做”。

观众：可观测是否等同于对云平台的监控？

陈自欣：可观测的范围远不止云平台。早期主要集中在基础设施层（Infra），随后扩展到应用性能监控（APM），再到业务层观测，如今已经延伸到 Agent 层面。本质上，可观测是由 metrics、logs 和 trace 等多种数据形式构成的综合能力，通过被观测对象主动输出数据，从而支持多维度分析与问题定位，因此它是一个多层级、组合式的体系。

孙佳林：可以简单理解为，监控回答的是“哪里出了问题”，而可观测不仅回答“为什么出问题”，还可以进一步支持分析“应该如何解决”，其能力更加全面多维。

观众：博物馆等文化单位部署 AI 或 Agent 时，是否可以在保证数据安全的前提下离线部署？

陈自欣：对于这类机构，由于其对信息安全要求较高，部署方案需要更加谨慎，建议优先咨询相关主管部门或参照安全规范，以确保合规性，避免潜在风险。

观众：OpenClaw 安装在空机器上，并对存储路径做权限控制后，Agent 是否还能正常工作？

陈自欣：从实践来看，如果希望 OpenClaw 发挥较好效果，通常需要赋予较高权限，“开放越多，能力越强”。如果需要更细粒度的控制，可以结合操作系统层面的目录权限进行限制，或者查看 OpenClaw 本身是否提供更精细的权限管理机制。不过在实际使用中，很多人会选择直接开放全部权限以简化使用。

孙佳林：我个人也是开放较多权限，但这确实存在风险。

陈自欣：确实如此，因此使用时必须清楚自身操作带来的影响，这一点往往也是最难做到的。

孙佳林：建议在非工作电脑或沙箱环境中运行。

陈自欣：实践中我通常会采用“实验环境 + 生产环境”的方式，先在隔离环境中验证，再逐步迁移到正式环境。

观众：未来 Agent 是否会具备较强的通用性，例如少量 Agent 覆盖大部分业务场景？

李昌昊：我认为这是一个必然趋势。当前无论是通用 Agent 还是代码类 Agent，其通用能力都在持续增强，通过叠加不同 Skill，理论上可以覆盖绝大多数业务场景。

孙佳林：从企业实践来看，通用化和生产化仍面临安全、资源利用率以及分布式记忆等挑战，但整体趋势确实是朝着通用化和生产化发展。

陈自欣：目前 MCP 尚未具备渐进式披露的能力，在加载后导致上下文臃肿的情况，消耗大量的 token 。未来 MCP 可能有两个走向， 第一是重要性下降，只在留在部分场景的使用，而不是唯一的选择，二是协议本身进行重构，但未来的走势仍需观察。

章平：在实际应用中，企业通常会同时使用 MCP 和 Skill：前者用于通用能力，例如数据接口；后者用于业务定制，实现更垂直的功能。

陈自欣： 可以进一步理解为，MCP 更适用于探索阶段，用于灵活调用与试错；而当流程稳定后，则会将其固化为 Skill，通过 API 或代码直接调用执行。可以将 MCP 视为“探索工具”，Skill 视为“执行工具”，两者在不同阶段各有价值。

会议推荐

QCon 全球软件开发大会·2026 北京站将于 4 月 16 日 -18 日正式举办。本届大会以“Agentic AI 时代的软件工程重塑”为主题，聚焦 100+ 重磅议题，汇聚来自阿里、腾讯、字节跳动、小米、百度等一线科技企业与创新团队的技术专家，围绕 AI 工程化、系统架构与研发模式演进展开深入探讨。更多详情可扫码或联系票务经理 18514549229 进行咨询。