Redis, Navy Federal Curb Multi-Agent AI as Chained Errors Hit 40%

链式错误率达40%，Redis与Navy Federal收紧多智能体AI应用 级联自主智能体会导致多步可靠性骤降至约60%，迫使企业工程师放弃多智能体集群，转而采用确定性语义路由与受约束的单智能体流水线。 业内从业者打破了当下普遍的多智能体炒作，指出复杂的编排器-集群架构在生产环境中常因复合错误率、JSON Schema脆弱性以及严格的合规壁垒而失效。专家组倡导采用确定性意图路由、具备程序性记忆的动态上下文引擎，以及追踪组件准确率、执行轨迹路径与运营成本上限的严谨“三层蛋糕”评估策略。为优化基础设施经济效益，专家建议先在前沿模型上进行原型设计，随后再迁移至具有深度缓存、微调过的开源权重模型，并辅以持续的、测试驱动的人工评估闭环。 生产级智能体的企业级评估需要采用多指标方法，全面追踪组件准确率、轨迹路径、延迟、计算成本上限、输出Token长度以及LLM重试频率。 (2:22) 幻觉往往源于静态上下文而非生成失败，因此需要可导航的动态上下文引擎，以及能够随时间沉淀问题解决启发式经验的程序性记忆。 (8:27) 盲目扩大LLM上下文窗口会导致上下文腐化并降低智能体性能，这类似于在未解决底层数据检索瓶颈的情况下单纯扩大CPU缓存。 (11:48) 模型上下文协议（MCP）已成为工具调用的主流标准，而复杂的自主多智能体交接框架在很大程度上仍停留在学术层面且较为脆弱。 (14:41) 级联自主多智能体集群会导致错误率复合累加——端到端任务完成率从95%骤降至约60%——这使得单智能体语义路由器成为生产环境中更可靠的替代方案。 (18:10)

Deploying generative AI agents in enterprise production requires shifting away from complex multi-agent hype toward deterministic constraints, rigorous context engineering, and continuous operational evaluation, according to an industry panel hosted by Ai4. The Fragility of Multi-Agent Architectures (18:10) Panelists push back forcefully against claims of widespread enterprise multi-agent adoption. Simba Khadder of Redis challenges reports suggesting a 66% deployment rate, stating that production multi-agent usage remains virtually non-existent in risk-averse institutions like global banks. The common pattern of using a central orchestrator to coordinate autonomous sub-agents suffers from severe compounding error rates. Waqas Makhdum of Nebius explains that even if individual agents boast a 95% completion rate, chaining 10 to 15 agents drops end-to-end reliability to roughly 60%. To circumvent orchestration fragility and schema breaks caused by raw JSON handoffs, Redis recommends semantic routing rather than agent hierarchies. In an implementation for a major airline, Redis deployed its Iris Intent Router to inspect user intent per turn and dynamically swap system prompts and toolsets into a single execution layer. This achieves the appearance of specialization without the vulnerability of multi-agent handoffs. Context Quality over Context Quantity (8:27) Production failures are often driven by poor context management rather than raw generative limitations. Khadder argues that hallucinations predominantly reflect missing information, critiquing traditional linear RAG for delivering static documents upfront that cannot adapt to multi-turn iterative reasoning. Instead, agents require dynamic context engines paired with procedural memory—the retained knowledge of operational heuristics and diagnostic procedures that develop across complex workflows. Conversely, providing excessive raw context introduces operational degradation. Serg Masís of Syngenta notes that providing an unfiltered, alphabetical list of 1,000 target pests to a fungicide query causes models to output arbitrary top entries that are technically accurate but domain-irrelevant. Rahul Zende of Navy Federal Credit Union compares naive context expansion to enlarging CPU cache memory indefinitely, emphasizing that expanding window sizes does not fix state transition bottlenecks or prevent context rot in multi-day workflows. Deterministic Guardrails and Domain Specialization (22:53) In production environments, autonomous agency should be restricted to strictly necessary components, while core business logic remains deterministic. Masís points out that Syngenta relies on classical machine learning models for core predictive tasks, such as forecasting seasonal crop pest pressures, while using agents primarily as natural language interfaces to query these deterministic models and format outputs. Deterministic constraints are especially critical in specialized fields like agriculture. Despite agriculture occupying 38% to 39% of the world's land surface and employing 26% of its workforce, Masís highlights that agricultural science comprises only 0.5% to 0.7% of public pre-training corpora. Because general-purpose frontier models underrepresent deep agronomic knowledge, deploying unconstrained agents without domain-specific data and rigid guardrails invites operational failure. Lifecycle Economics and Frontier-to-Open Prototyping (26:48) To balance innovation with cost, Redis practices a top-down model strategy. Development begins on top-tier frontier models like Claude Opus to establish a feasibility baseline and prove business ROI. Once validated, architectures transition to open-weight or fine-tuned open-source models, allowing teams to optimize inference latency, control uptime, and decouple agent harnesses from underlying models as pricing shifts. Makhdum highlights that long-running agent workflows spanning 10 to 60 minutes are inherently asynchronous and latency-tolerant compared to customer-facing chatbots. This enables engineering optimizations such as extreme key-value (KV) caching. Achieving KV cache hit rates up to 95% on repetitive context frames reduces operational compute costs by 80% to 90%, making large-scale agent pipelines economically sustainable. Layered Evaluation and Behavioral Baselines (32:15) Evaluating production agents requires moving beyond basic benchmarks toward structured, multi-dimensional frameworks. Zende outlines Navy Federal Credit Union's "three-layer cake" metrics framework, which evaluates individual component precision and latency, trajectory-level governance compliance and valid tool execution, and operational costs per dollar ceiling. In regulated finance, auditability and explainability are mandatory to justify replacing compliant legacy systems. Rather than drafting elaborate pre-launch PRDs or depending on sparse explicit user ratings, Khadder advises teams to deploy simple 5-minute RAG baselines and run 15-question sniff tests on small user cohorts. Teams can then monitor implicit signals—such as query repetition, session abandonment, and churn—to determine whether the agent truly addresses the underlying business problem before investing in deeper agentic memory or complex tooling. Enterprise production deployment favors single-agent workflows grounded by semantic routing, deterministic business logic, and continuous behavioral telemetry over autonomous multi-agent swarms. Major unresolved challenges remain in standardizing inter-agent communication protocols and achieving the granular auditability required for highly regulated industries.

来自农业、金融和云计算等领域的企业技术负责人指出，多智能体系统在工业级生产中的落地远不及市场宣传普及，当前企业落地更侧重于结合动态上下文治理、确定性业务约束以及严格的评估体系来构建稳健的单智能体架构。 多智能体架构神话与语义路由替代方案 (18:10) 针对斯坦福 HAI / OSWorld 报告提出的智能体部署率从 12% 跃升至 66% 的说法，Redis 的 Simba Khadder 明确反驳称，在全球大型银行等企业生产环境中，多智能体协同几乎不存在。业内常见的“中央调度器委托子智能体集群”模式因可靠性问题屡屡失败，例如 Claude Code 仍将多智能体协作模式保留为默认关闭的 Alpha 状态。Nebius 的 Waqas Makhdum 指出，多智能体链路面临复合故障概率的致命缺陷：即使单个智能体具备 95% 的任务完成率，串联 10 至 15 个智能体后的端到端成功率将骤降至约 60%。Navy Federal Credit Union 的 Rahul Zende 也建议企业团队避免采用多智能体系统，因为金融机构难以承受其引发的延迟膨胀、推理成本上升以及可解释性与合规审计缺失。为了规避此类系统性崩溃，企业正在转向更实用的替代方案。例如，Redis 利用 Iris 意图路由器（语义路由）为某大型航空公司解决了 15 个独立客户端智能体的协调问题。该架构无需依赖多层 LLM 自主调度，而是在对话的每一轮动态检测用户意图，将特定的系统提示词和工具集按需注入单一执行引擎，在避免多智能体脆弱链条的同时，对外呈现专业智能体的协作效果。此外，虽然 Model Context Protocol (MCP) 在过去 12 至 18 个月内快速成为工具调用的事实标准，但在高层多智能体握手协议（如 Google A2A 或 IBM 实验框架）方面，业界仍缺乏能够应对遗留系统数据突变与 JSON 结构脆弱性的可靠生产标准。 上下文瓶颈：动态程序记忆与信息过载风险 (8:27) 在智能体记忆与状态管理层面，专家们认为模型幻觉的核心诱因在于运行时缺乏精准的上下文，而非纯粹的生成能力缺失。Simba Khadder 批评传统的检索增强生成（RAG）属于单向线性模式，仅在生成前做一次性静态文档检索，无法支持长时间运行的代码编写或故障排查等迭代推理循环。真正的智能体记忆应当超越简单的用户画像偏好，建立能够积累问题解决经验的“程序性记忆”（Procedural Memory），让系统能够在推理回路中主动探索、检索最新状态并沉淀排障规则。此外，企业工作流必须支持异步状态序列化，以便在长达数天的欺诈核验等业务中断后无缝恢复执行，避免重新启动整个流程消耗冗余 Token。然而，上下文并非越多越好。Syngenta 的 Serg Masís 强调了上下文过载带来的负面效应：在农业与科学场景中，若直接注入未经筛选的信息（如按字母排序的 1000 种杀菌剂防治对象），智能体可能仅仅机械地提取前十项，给出一个在技术上正确但在业务上毫无价值的输出。Rahul Zende 结合计算机体系结构指出，盲目扩大大语言模型的上下文窗口无异于无节制地扩大 CPU 缓存，根本无法解决数据检索的结构性瓶颈，反而会导致难以追踪的状态转移混乱和上下文劣化。 领域数据匮乏下的确定性约束与模型经济学 (22:53) 为了在真实业务中控制不确定性，企业更倾向于推行以确定性逻辑为主导的混合架构。Serg Masís 表示，由于通用基础模型的预训练数据中农业科学内容仅占 0.5% 至 0.7%，远无法匹配农业占据全球约 38% 至 39% 土地和 26% 劳动力的实际体量，团队不能依赖基础模型开箱即用的推理。Syngenta 采用“伪智能体”策略，将具体的气候和病虫害预测任务交由传统机器学习模型完成，智能体仅作为接口负责查询、解析并生成结构化摘要，同时隐藏非必要的工具上下文以抑制幻觉。在工程经济学与模型选型上，团队普遍采用自顶向下的分层推进路径。Simba Khadder 说明，Redis 会优先使用顶级前沿模型（如 Claude Opus）来验证业务可行性上限，一旦完成 POC 验证并证明商业投资回报率（ROI），就会转向更具成本优势的开源或微调模型。Waqas Makhdum 指出，如 Kimi 等蒸馏和开源权重的崛起加速了这一演进，企业应当将调度框架与底层模型解耦以便随时替换。此外，由于大部分复杂的异步后台任务（如运行 10 到 60 分钟的分析或 Revolut 式的反欺诈画像分析）对延迟不敏感，工程团队可以通过高达 95% 的键值（KV）缓存命中率，将实际计算成本削减 80% 至 90%。 全生命周期治理：三层评估与测试驱动落地 (32:15) 生产环境部署要求建立贯穿开发全周期的量化评估体系。传统机器学习依赖现成标注数据集，而智能体开发则需要根据抽象业务需求逆向推导，因此必须推行测试驱动开发（TDD）。Syngenta 要求在项目第一天就必须联合领域专家构建经过人类标注的“黄金数据集”，并在评估时超越单一的成功/失败指标，提供涵盖工具选择错误、提示词缺陷或检索失效的描述性根因诊断。针对受严格监管的金融场景，Rahul Zende 提出了“三层蛋糕”指标框架：第一层为组件级（Component Level），监控精确率、召回率与单模块延迟；第二层为执行轨迹级（Trajectory Level），审计工作流路径合规性、提示词版本和工具调用轨迹；第三层为运营级（Operational Level），严密监控单次请求成本上限以确保业务 ROI。在人机协同（HITL）与系统测试策略上，受访者一致主张将人类主动干预压缩至最低限度，仅在关键合规节点或 OCR 文档审核等高风险盲区保留人工，以防止非标准的人力介入拖垮扩展性。针对早期真实样本不足的问题，团队可利用大模型基于高价值历史输入生成对抗性合成测试用例，并通过部署辅助评估智能体对测试失败用例进行自动化聚类，从而实现对系统性漏洞的成批修复。 该讨论表明，企业级 AI 智能体的真正壁垒不在于追求复杂的自主集群概念，而在于结合业务实情设立极简基准、严格限定自主性边界，并通过标准化工具协议与深度遥测构建可持续监控的闭环工程体系；如何在保持高确定性的同时让智能体安全承接更长链条的自主操作，仍是行业持续探索的课题。

## Background 该内容由 YouTube 频道 Ai4 于 2026 年 8 月 21 日发布。视频记录了一场关于真实世界 AI Agent 部署的圆桌讨论，汇聚了来自 Syngenta、Navy Federal Credit Union、Redis、Nebius 和 Western Governors University 的多位技术专家与产品负责人，重点探讨多智能体协作、状态与上下文管理、落地评估及企业级合规挑战。 ## TL;DR 圆桌嘉宾围绕企业级 AI 智能体落地的真实技术挑战展开深度剖析。与会专家打破了多智能体编排与中心调度器的神话，指出当下多智能体在复杂生产流水线中因复合错误率极易崩溃，并主张采用语义路由器与确定性工作流来保障系统稳定性。针对长运行任务中的上下文退化与状态管理难题，讨论提出了程序性记忆、KV Cache 高度复用以及涵盖组件、轨迹与运营的“三层蛋糕”评估体系。嘉宾们一致呼吁开发者摒弃过度工程化，以明确的业务成果为导向，建立测试驱动开发与持续迭代的评估闭环。 ## Atmosphere & style 整场对谈氛围务实、克制且充满工程第一线的犀利洞察。与会专家直言不讳地戳破了行业对多智能体架构的过度炒作，在分享踩坑经历时幽默风趣却字字切中痛点。讨论在学术前沿探索与强监管企业严苛落地的拉锯中展开，呈现出冷静清醒的技术反思与扎实的工程底色。 ## Key takeaways - [02:22](https://www.youtube.com/watch?v=fV044e3-QdU&t=142s) 生产级智能体评估需结合多维指标：除了模型组件级精度外，更需纳入时延、Token 成本、重试次数以及轨迹级（Trajectory-level）合规与业务价值回报。 - [08:27](https://www.youtube.com/watch?v=fV044e3-QdU&t=507s) 告别传统线性 RAG：复杂长程任务依赖动态可导航的上下文引擎，并需要从静态偏好记录升级为掌握解题经验的“程序性记忆”（Procedural Memory）。 - [11:48](https://www.youtube.com/watch?v=fV044e3-QdU&t=708s) 上下文并非越多越好：过载或无序的背景信息会导致大模型注意力偏离，容易输出看似技术正确但对业务人员毫无实用价值的答案。 - [18:10](https://www.youtube.com/watch?v=fV044e3-QdU&t=1090s) 多智能体复合错误率极高：单智能体 95% 的任务完成率在串联 10-15 步后整体成功率断崖式暴跌至 60% 左右，多智能体协同在工业落地中仍缺乏成熟标准。 - [18:10](https://www.youtube.com/watch?v=fV044e3-QdU&t=1090s) 用语义路由器（Intent Router）替代嵌套多智能体编排：根据用户意图动态注入专属 Prompt 与工具集，是当前规避多智能体失控的最有效实践方案。 - [21:11](https://www.youtube.com/watch?v=fV044e3-QdU&t=1271s) 强监管行业要求端到端可追溯性：金融等高合规要求场景对黑盒漂移零容忍，缺乏可解释性与严密审计追踪的多智能体系统难以在核心业务中立足。 - [22:53](https://www.youtube.com/watch?v=fV044e3-QdU&t=1373s) 确定性工作流优于盲目自主化：业务流程应尽可能保持确定性，仅在必要节点赋予 Agent 自主权，并深度复用成熟的经典机器学习预测模型以避免幻觉。 - [26:48](https://www.youtube.com/watch?v=fV044e3-QdU&t=1608s) 前沿模型验证到开源微调降本路径：PoC 阶段先用顶尖前沿模型建立评测基线验证 ROI，规模化部署时切换为微调开源模型，结合高达 95% 的 KV Cache 复用可降本 80%-90%。 - [30:08](https://www.youtube.com/watch?v=fV044e3-QdU&t=1808s) 智能体测试驱动开发（TDD）：颠覆传统数据优先思维，自第一天起由业务专家建立“黄金数据集”，以细粒度归因标注倒推智能体配置与流程调优。 - [32:15](https://www.youtube.com/watch?v=fV044e3-QdU&t=1935s) 智能体合规与评估的“三层蛋糕”体系：底层聚焦组件与模型指标，中层把控决策轨迹与治理合规规则，顶层严格核算单次请求成本与实际业务收益。 - [34:18](https://www.youtube.com/watch?v=fV044e3-QdU&t=2058s) 警惕过度工程化：在堆叠复杂 Agent 架构前先搭建最简原型（如 5 分钟 RAG）设立 Baseline，通过重复提问、用户流失等隐式反馈衡量真实的业务增量。 - [38:58](https://www.youtube.com/watch?v=fV044e3-QdU&t=2338s) 利用分析 Agent 实现批量故障聚类：借助大模型合成对抗测试用例，并引入专门的审查 Agent 对失败样本进行模式聚类（Failure Modes），实现问题的前置拦截与持续学习闭环。 ## Detailed walkthrough ### [00:04](https://www.youtube.com/watch?v=fV044e3-QdU&t=4s) 嘉宾介绍与现场调查：多智能体协作成为新焦点 主持人 Ram Kumar Nimmakayala（Western Governors University 企业级 AI 首席产品经理）首先组织了这场圆桌，并邀请来自各个领域的专家进行自我介绍。Nebius 的开发者关系与社区负责人 Waqas Makhdum 介绍了他们作为底层 AI 云平台所提供的能力，涵盖从 GPU 算力访问、托管推理到面向开发者、AI 原生初创公司和大型企业的 Agent 开发工具栈；Redis 的 AI 产品负责人 Simba Khadder 提到自己此前是创业公司创始人，因被 Redis 收购而加入；Navy Federal Credit Union 的主任级资深数据科学家 Rahul Zende 则来自企业级 AI 战略团队。Rahul 一开场就感慨，相比于去年，今年台下举手表示已在生产环境中部署 AI Agent 的观众数量激增，令人振奋。 来自农业科技巨头先正达（Syngenta）的首席 AI 科学家 Serg Masis 介绍了自己负责的智能体构建、编排与评估工作，并幽默地指着自己的手腕解释说，在大家开口询问之前先说明一下，他手上戴的是一个 3D 打印的固定夹板，因为前不久不小心骨折了。在正式进入讨论前，Serg 还现场向台下抛出了一个互动问题：“有多少人已经在构建多个协同工作的多智能体编排（Multi-Agent Orchestration）系统？”现场大量举起的手臂展现出生产级 Agent 研发正在向多智能体协作迅速演进的趋势。 --- ### [02:22](https://www.youtube.com/watch?v=fV044e3-QdU&t=142s) 落地生产环境的真实智能体：从农业助手、金融风控到企业内部运维 主持人请各位嘉宾分享各自领域已正式投入生产的智能体类型。Serg Masis 详细介绍了先正达的核心产品 Cropwise AI。作为面向农业场景的智能体，它允许农户针对农田状况、农作物生长、病虫害防治以及提升农场运营效率（无论出于可持续发展目标还是经济考量）进行深度问答。其后台融合了卫星遥感影像、无人机监测以及自动化报告智能体等前沿技术。针对生产流水线的评估指标，Serg 强调自己是“多指标评估（Multimetric Evaluation）”的坚定拥护者，不仅关注模型精度（且精度在各个独立组件上都有细分标准），还必须将推理延迟、调用成本、生成长度以及大语言模型（LLM）的重试生成次数纳入综合考量。 Rahul Zende 分享了金融领域的落地现状。在 Navy Federal Credit Union，绝大多数智能体主要聚焦于企业内部生产力提升，而非直接面向终端会员或客户。在评估指标上，除了 Serg 提及的组件级精度指标外，金融机构高度依赖“轨迹级指标（Trajectory-level Metrics）”与运营指标——不仅要看工具的精准度，更要评估其创造的商业价值，并严格监控智能体是否始终保持在合规与安全治理阈值之内。 Simba Khadder 则从 Redis 的平台视角指出，智能体大致分为三类：为客户构建的、赋能客户自己构建的、以及企业内部自用的。Redis 内部已深度运行着用于处理云基础设施异常的“AI SRE 智能体”以及监控平台重大变更的自动化智能体。Simba 直言：“我个人名下大概就同时跑着至少 100 个智能体，在不久的将来，每个企业员工可能都会有上千个智能体在替他们工作。” ```mermaid flowchart TD accTitle: 生产级智能体评估多维指标模型 subgraph S1["组件级指标 (Component-level)"] A1["基础准确率 / 精准度"] A2["生成长度 / Token消耗"] A3["LLM 重试生成次数 (Retries)"] end subgraph S2["系统运营级指标 (Operational)"] B1["推理时延 (Latency)"] B2["端到端成本 (Cost)"] B3["轨迹级评估 (Trajectory Metrics)"] end subgraph S3["企业治理与商业指标 (Governance & Value)"] C1["安全合规阈值拦截"] C2["实际生产力 / 业务回报"] end ``` - **农业落地（先正达 Cropwise AI）**：整合无人机与卫星影像，辅助农户进行病虫害决策与农场财务/环保运营。 - **金融落地（Navy Federal）**：以内保生产力为主，强调治理门槛与智能体决策轨迹分析。 - **云基础设施落地（Redis）**：AI SRE 自动化排查云端故障与系统异动。 --- ### [06:25](https://www.youtube.com/watch?v=fV044e3-QdU&t=385s) 生产规模、蓝图生态与“别再造股票/旅游智能体” 当被问及当前究竟有多少企业将 Agent 推向生产时，Waqas Makhdum 直言目前很难给出精确数字，因为业内存在明显的概念泛化，许多传统工作流如今也纷纷贴上了“Agent”的标签。目前市场呈现出两极格局：一方面是初创公司推出封装好的专属智能体（如 AI SRE、代码生成智能体、客服智能体）；另一方面是大企业内部广泛的多智能体实验，例如需要 10 个智能体紧密协作的营收运营（RevOps）智能体。 谈及智能体开发生态时，Waqas 现场呼吁开发者将精力投入真正有价值的场景中：“如果你正在构建智能体，拜托不要再做选股智能体或旅游规划智能体了，这个世界不需要更多这类东西了。”针对当前多数开发者依赖两三家封闭大模型实验室 API 的现状，Nebius 推出了“Agent Blueprints”（智能体蓝图），旨在建立横向乃至纵向场景的开源参考实现，推动构建一个开放、解耦的 Agent 全栈开发生态。 --- ### [08:27](https://www.youtube.com/watch?v=fV044e3-QdU&t=507s) 智能体上下文引擎与程序性记忆：告别传统线性 RAG 主持人将话题转向智能体在复杂生产环境下的核心痛点：当把智能体从受控环境迁移至动态的企业实际业务流中时，预设的状态假设常常被打破。对此，Simba Khadder 深刻地指出：“如今能正常工作的智能体与失败的智能体之间，唯一的差别就在于上下文（Context）。”过去行业普遍归咎于“模型幻觉”，但如今如果模型出现幻觉，根本原因在于没有获取到正确的上下文而被迫盲猜。 Simba 剖析了传统 RAG（检索增强生成）与真正智能体之间的本质矛盾：传统 RAG 在架构上是**严格线性**的，即在最开始单次抓取文档并直接丢给 LLM。然而，在长时间运行的场景（如代码智能体可能持续执行数十分钟）中，这种静态机制必然崩溃。真正可靠的智能体必须具备一个**动态可导航、持续保鲜且具备复合积累能力（Compounding）的上下文引擎**，使智能体能够在推理循环（Reasoning Loop）中按需自主探寻上下文、推理分析、再进一步获取新上下文。 ```mermaid flowchart LR accTitle: 线性 RAG 与动态智能体推理上下文循环对比 subgraph LinearRAG["传统线性 RAG (Linear RAG)"] L1["用户提问"] --> L2["单次向量检索 Docs"] L2 --> L3["单次输入 LLM"] L3 --> L4["单次输出 (易断层/幻觉)"] end subgraph AgentLoop["动态上下文推理循环 (Agent Context Engine)"] A1["任务触发"] --> A2["推理与规划 (Reasoning)"] A2 --> A3["动态按需检索/执行 Tool"] A3 --> A4{"是否需要更多上下文?"} A4 -- 是 --> A2 A4 -- 否 --> A5["程序性记忆更新 / 输出"] end ``` Simba 进一步阐述了记忆架构的升级。当前许多人眼中的 Agent Memory 还停留在“Simba 喜欢红色”这类静态偏好声明层面；但真正强大的是**程序性记忆（Procedural Memory / Stateful Memory）**——智能体学会并记住“如何解决特定问题”。例如 SRE 智能体随着使用经验的积累，会逐渐领悟到“虽然日志表面报的是这个错误，但背后实际意味着 Kubernetes 底层出现了异常”，让智能体越用越聪明。 --- ### [11:03](https://www.youtube.com/watch?v=fV044e3-QdU&t=663s) 企业级异步状态与长周期工作流挑战 Waqas Makhdum 对 Simba 关于上下文引擎的观点表示强烈赞同，并补充了企业在异步长周期执行中所面临的状态管理难题。当前工业界在这类问题的解决上依然处于初期摸索阶段。 在反欺诈等实际企业业务场景中，智能体发现风险并发出核验后，往往需要等待客户数小时甚至三四天后才能收到回执。在朴素的无状态设计下，系统要么白白空转消耗大量 Token，要么只能被迫从头重跑整个工作流。如何在漫长的异步等待后精准恢复智能体运行状态、延续先前的任务上下文而不浪费 Token 与算力，是企业部署高可用智能体系统亟待攻克的技术关卡。 ### [11:48](https://www.youtube.com/watch?v=fV044e3-QdU&t=708s) 上下文并非越多越好：农业场景下的信息过载教训 讨论由智能体之间（agent-to-agent）的上下文传递切入。Syngenta 的首席 AI 科学家 Serg Masis 指出，虽然保持上下文对于智能体而言至关重要、堪称核心生命线，但这并不意味着上下文越多越好——“信息过多”同样会引发严重翻车。当模型接收到海量背景信息时，系统往往不是无法解析，而是会在噪音中抓错重点：模型给出的回答在技术细节上完全准确，但对人类业务人员来说却毫无实用价值。 Serg 举了农业植保场景的生动案例：如果向智能体提问“某种杀菌剂主要针对哪些农作物病虫害？”，数据库中可能匹配出成百上千种潜在害虫。如果上下文按字母顺序排列传递，智能体可能老老实实提取了前 10 种害虫列在答案中；虽然回答属实，但排在前 10 位的害虫根本不是该杀虫剂实际应用中最关键、最具威胁的靶标。因此，团队必须下足功夫精炼上下文，过滤无关干扰，只将与最终用户意图最相关的核心信息喂给模型。 - 上下文过载会导致模型在处理时发生注意力偏离，输出“看似正确却无价值”的回答。 - 上下文的组织与排序（如简单按字母排序）可能直接误导智能体的决策权重。 --- ### [13:13](https://www.youtube.com/watch?v=fV044e3-QdU&t=793s) 强监管行业的上下文退化与内存状态管理 来自 Western Governors University 的 Ram Kumar Nimmakayala 提到教育行业与金融行业的共性——两者均处于严苛的监管环境（regulated environment）中，并借此向 Navy Federal Credit Union 的 Rahul Zende 提问：在企业实操中，上下文退化（context rot）通常最先发生在哪里？Rahul 明确指出，核心症结在于“状态管理（state management）”。在当前关于 AI 智能体的讨论中，人们往往把记忆管理当成一个铁板一块的单体（monolith）来看待，这是一种严重误解。 Rahul 结合自身学习计算机体系结构的背景提出精妙类比：智能体的上下文与内存机制，就像计算机系统中的高速缓存（Cache）与系统内存（RAM）一样。如果单纯把 Cache 做得极大，不仅解决不了算力与调度的根本问题，反而会滋生更多的副作用与管理开销。一旦智能体长时间运行、需要执行多步推理，甚至像“后空翻”一样折返到先前的决策节点时，如果状态追踪没有严密的隔离和管理，回溯（retracing）与修正就会变得异常困难，甚至全面崩溃。 ```mermaid flowchart LR accTitle: 智能体状态管理与上下文退化 subgraph AgentExec["智能体推理执行"] direction TB A["长程任务推进"] --> B["需要状态折返 / 回溯"] end subgraph StateIssue["状态管理缺失"] direction TB C["单体式记忆膨胀"] --> D["上下文退化 / 状态混乱"] end AgentExec --> StateIssue StateIssue --> E["任务崩溃与审计失真"] ``` --- ### [14:41](https://www.youtube.com/watch?v=fV044e3-QdU&t=881s) 多智能体编排的技术分层与行业标准真空 随着单智能体话题拓展到多智能体编排（multi-agent orchestration），Nebius 的 VP Waqas Makhdum 对当前多智能体落地的现状泼了冷水。他直言，多智能体协同在很大程度上依然停留在学术研究和论文阶段；早期初创公司描绘的前景非常诱人，但真正在工业生产环境中大规模跑通的极其罕见。Waqas 将多智能体编排的技术挑战拆解为四个主要阶段或技术模块： 1. **任务分解与群智分配（Task Decomposition & Sub-agent Swarm）**：如何将复杂任务拆分并分发给子智能体。这个领域目前根本不存在公认的标准框架。框架的核心目标本应是提供跨系统、跨团队的底层原语（primitives），而现实中却缺乏标准化规范。 2. **上下文传递（Context Pass-Through）**：目前绝大多数系统高度依赖 JSON 格式的输出传递数据。这在复杂的企业场景中极其脆弱——遗留记录系统（legacy system of records）无法精准传递上下文，且底层数据结构（Schema）稍有变动，解析链路就会直接断裂。 3. **工具调用与通信协议**：这是相对有所进展的环节。例如 Model Context Protocol（MCP）虽然在业内引发了广泛争议、毁誉参半，但历经 12 到 18 个月的演进，已经取得了实质性的采用。 4. **智能体交接与任务委派（Agent Handover & Delegation）**：诸如 Google 尝试推动的 A2A 标准或 IBM 的协议规范，绝大多数依然停留在实验室与学术论文层面，下游针对多智能体协同输出的消费逻辑高度定制化且无章可循。 前沿实验室如 OpenAI 和 Anthropic 目前倾向于通过推出轻量级 SDK 的模式来探索多智能体或集群（swarm）问题，但这仍处于极其早期的探索阶段。 --- ### [18:10](https://www.youtube.com/watch?v=fV044e3-QdU&t=1090s) “中心编排器+子智能体”神话破灭与语义路由的破局实践 Ram Kumar 此时提出了尖锐的质疑：斯坦福 HAI 等机构发布的报告显示，去年 OSWorld 评测中生产环境智能体仅有 12% 左右，而如今已有说法称渗透率攀升到了 66% 左右，这与 Waqas 口中的“停留在概念阶段”形成鲜明对比。Redis 的 AI 产品负责人 Simba Khadder 对此毫不留情地驳斥：如果指的是多智能体系统，66% 的采用率绝不可能真实存在；他几乎与全球所有大型银行都打过交道，在金融领域根本不存在这样广泛的多智能体落地。单智能体或许有一定渗透率，但多智能体在企业中极少被真正调通。 Simba 深入剖析了行业普遍遭遇的架构误区：所有人都在盲目尝试**“一个中心编排器（Orchestrator Agent）挂接大量子智能体（Sub-agents）”**的树状结构，但在高准确度生产要求下，这种架构无一例外全部失败。包括主流代码辅助大模型服务中的多智能体功能，即便依托海量数据和顶级算力，也大多被标记为“Alpha 测试”或在默认设置下直接保持关闭。针对某大型航空公司的真实案例，业务团队开发了 15 个独立界面的智能体且彼此割裂，各部门甚至为了争抢“谁来当中心编排器智能体”而爆发组织政治博弈。 为了打破这种僵局，Redis 团队帮助该航司引入了基于意图的语义路由器（Iris 架构中的 Intent Router）： ```mermaid flowchart TD accTitle: 基于语义路由的多智能体分发架构 UserReq["用户请求输入"] --> Router["Redis Intent Router\n(语义路由器)"] subgraph RoutingLogic["动态挂载上下文"] Router -->|"意图 A: 退改签"| A1["智能体 A\n(专属系统 Prompt + 工具集 A)"] Router -->|"意图 B: 行李追踪"| A2["智能体 B\n(专属系统 Prompt + 工具集 B)"] Router -->|"意图 C: 会员积分"| A3["智能体 C\n(专属系统 Prompt + 工具集 C)"] end A1 --> UserResp["统一输出响应给用户"] A2 --> UserResp A3 --> UserResp ``` 这种方案彻底放弃了动态的多级嵌套编排，用户在多轮对话中可能每一轮都在与完全不同的“智能体”交互，但用户感知不到切换——因为每一次交互的本质，只是语义路由器根据意图示例迅速匹配，动态注入了不同的 System Prompt 和对应的工具集。Simba 断言，这就是当前大模型与智能体能力的真实天花板，未来一年或许会有突破，但眼下唯有此路可行。Waqas 补充支持这一观点并披露了一组严酷的数据：某原生 AI 企业在单智能体任务完成率上能超过 95%，然而一旦把流程串联给 10 到 15 个智能体级联运行，整体工作流的成功率便断崖式暴跌至 60% 左右——直接“从 A+ 跌至 D-”。 --- ### [21:11](https://www.youtube.com/watch?v=fV044e3-QdU&t=1271s) 强监管视角：合规审计红线与多智能体反思 针对多智能体在运行中出现状态漂移（drift）、死循环以及引发金融合规风险的担忧，Rahul Zende 从金融机构的实操合规角度给出了极度审慎的建议。他甚至半开玩笑地承认，自己的观点在狂热的 AI 浪潮中听起来可能像个“卢德主义者（Luddite）”：除非有压倒性、经过严格量化证明的业务指标提升（metric lift），否则他会坚决阻止团队构建多智能体系统。 在信用卡与金融信用合作社业务中，端到端的审计追踪（auditory and traceability concerns）是绝对的第一优先级。多智能体系统带来的高额延迟开销、巨大的 Token 成本以及黑盒般的不可解释性，在严格的金融审计要求面前完全站不住脚。金融企业不可能去从底层研发保障这类系统不出差错的基础设施，在第三方平台能够提供真正透明、可解释且审计可追溯的多智能体平台之前，盲目推行多智能体落地是极度不负责任的。Serg Masis 随后接过话题表示完全赞同：在农业等严苛实体工业场景中，同样几乎见不到所谓的多智能体系统落地，智能体之所以被称为 Agent，核心在于其所赋予的自主行动力（agency），而失控的复杂协调只会放大系统的不稳定性。 - **多智能体复合错误率**：单智能体 95% 准确率在经历 10-15 步交接后，整体工作流成功率将稀释至约 60%。 - **金融机构核心诉求**：极度看重端到端可追溯性与合规审计日志，无法容忍多智能体带来的“黑盒漂移”与延迟暴增。 ### [22:53](https://www.youtube.com/watch?v=fV044e3-QdU&t=1373s) 确定性工作流与传统机器学习工具在特定行业中的结合 Serg Masis 强调，在设计智能体工作流时，应当尽可能地让系统保持“确定性”（deterministic），仅在绝对必要的环节才赋予智能体自主决策权（agency）。当引入多智能体协作时，不确定性会成倍叠加；而事实上，许多系统（例如生成报表的报告智能体）本质上只需要遵循确定性的数据处理和排版逻辑，并不需要过度复杂的动态规划。对于一些工具调用，他倾向于构建“伪智能体”（pseudo agent），对外隐藏工具的具体上下文，从而避免让智能体处理无关信息。 针对主持人关于 RPA（机器人流程自动化）与传统机器学习模型结合的提问，Serg 表示团队一直大量沿用成熟的经典机器学习模型库。例如，当农业用户（农民）需要预测当季或未来几周是否会出现某种特定病虫害时，系统会直接调用训练好的传统机器学习预测模型，智能体只需作为中介获取数据并呈现给用户，而不需要“无中生有”地让大语言模型去胡乱猜测。 ```mermaid flowchart LR accTitle: 农业智能体工作流与工具集成架构 subgraph InputStage["输入与调度"] User["农业用户 / 农民"] --> Agent["核心智能体 (确定性编排)"] end subgraph ToolStage["工具与传统模型层"] Agent --> MLModel["经典机器学习模型<br/>(病虫害预测等)"] Agent --> ReportTool["报表/数据处理工具<br/>(隐藏上下文的伪智能体)"] end subgraph OutputStage["结果输出"] MLModel --> Agent ReportTool --> Agent Agent --> Result["确定性结构化交付"] end ``` - **农业领域的训练数据失衡困境**：全球农业用地占地球陆地面积的约 38%–39%（其中牧场占绝大部分，耕地约占 10%），农业吸纳了全球 26% 的就业人口，贡献了全球 4% 到 10% 的 GDP； - **基础模型的数据代表性不足**：在公开的预训练数据集语料库中，农业相关文献仅占 0.5% 至 0.7% 左右，私有数据集中因充斥无关版权内容和 Reddit 社区帖文，农业数据占比更低； - **评估优先（Evaluation-first）**：由于基础模型在专业垂直领域极易产生不合理输出，像农业这样的关键行业必须建立评估优先、上下文精准注入的确定性工作流，无法直接裸用通用基础模型。 --- ### [26:48](https://www.youtube.com/watch?v=fV044e3-QdU&t=1608s) 开源模型、前沿模型与智能体工程降本架构 讨论转向开源与开放权重模型（Open-weight models）的应用前景。Simba Khadder 分享了 Redis 的工程实践哲学：所有项目在研发起步阶段一律优先采用最强的前沿基础模型（如 Claude Opus）进行 PoC 验证——"如果用最顶级的模型都做不出来，那说明当前技术条件下这件事就不可行"。通过顶级模型建立基准评估集（Eval Set）并向业务方证明 ROI 后，再在扩展阶段（Scale）迁移至开源或小型微调模型，以此牢牢掌控系统可用性与底层细节。 ```mermaid flowchart TD accTitle: 智能体模型选型演进与降本路径 subgraph Phase1["第一阶段：可行性验证与基线建立"] A["前沿基础模型 (如 Claude Opus)"] --> B["构建基准评估集 (Eval Set)"] B --> C["验证业务 ROI 与架构可行性"] end subgraph Phase2["第二阶段：规模化部署与自主可控"] C --> D["模块化智能体架构 (模型可热插拔)"] D --> E["针对性微调 (Fine-tuning)"] E --> F["小型开源 / 开放权重模型"] end subgraph Phase3["第三阶段：生产环境极致优化"] F --> G["长运行任务容忍轻微延迟"] F --> H["高达 95% KV Cache 复用降低 GPU 负载"] G & H --> I["整体推理成本直降 80% - 90%"] end ``` Waqas Makhdum 对此深表赞同，并指出行业范式正在巨变，开源领域早已不仅仅是前沿基础模型的简单蒸馏版（例如 Kimi K3 等模型的实力已经能够与头部闭源模型同台竞技）。在构建智能体架构底座（Harness）时，核心在于**保持模型层的可插拔性（Swappable）**。以金融科技公司 Revolut 构建按用户画像进行欺诈检测的智能体为例，由于多数智能体任务属于长周期运行（耗时可能达数分钟甚至一小时），对端到端延迟并不敏感，因此团队可以通过创新的工程手段大幅降低成本： - **KV Cache 深度复用**：在长流程中实现高达 95% 的 KV Cache 命中率，大幅减少对 GPU 计算核心的重复冲击； - **算力成本断崖式下降**：结合小型开源微调模型与缓存策略，可将整体推理账单降低 80% 至 90%。 --- ### [30:08](https://www.youtube.com/watch?v=fV044e3-QdU&t=1808s) 测试驱动开发（TDD）与多智能体评估体系 在进入智能体评估机制的讨论时，Serg Masis 直言从传统机器学习转向 AI 智能体开发时曾经历过思维认知的颠覆。在传统 ML 中，研发路径通常是"从数据出发向前推导"（Data-first），只要有特征数据和明确的目标变量即可训练和评测；而在智能体时代，产品开发更像是"从目标终局倒推配置"（Configuration-driven development）。 - **黄金数据集（Golden Datasets）的绝对前置**：在 Syngenta 这样的高门槛领域，项目必须自第一天起依赖业务专家的深度参与建立黄金标注集，没有高质量评估集项目就绝不开工； - **细粒度归因标注**：评估指标绝不能停留在简单的二元结果（即不能仅仅标记"对"或"错"），标注必须包含描述性原因，以支持白盒化定位智能体链路中具体哪个子组件或工具调用出现了逻辑偏差； - **反向测试驱动开发**：确立了"测试评估驱动开发"（TDD）的模式，先确立评估基准，再反向调优智能体的 Prompt 与流程配置。 --- ### [32:15](https://www.youtube.com/watch?v=fV044e3-QdU&t=1935s) 合规环境下的智能体可解释性与“三层蛋糕”指标模型 针对金融与合规场景下极为苛刻的可解释性要求，Navy Federal Credit Union 的 Rahul Zende 提出了将智能体可观测性与合规指标解构为“三层蛋糕”（Three-layer cake）的评估体系： ```mermaid flowchart TD accTitle: 智能体系统评估与合规体系的三层蛋糕模型 subgraph Layer3["业务与运营层 (Operational Level)"] L3["单次请求成本 (Dollars per Request) 与业务底线 ROI"] end subgraph Layer2["轨迹与治理层 (Trajectory / Governance Level)"] L2["工作流治理规则遵循 + Prompt/信息版本控制 + 工具调用精准度"] end subgraph Layer1["组件与模型层 (Component Level)"] L1["传统基础指标 (准确率 Accuracy、精确率 Precision 等)"] end Layer1 --> Layer2 Layer2 --> Layer3 ``` 1. **组件层指标（Component Level）**：关注底层的经典机器学习与 NLP 性能指标，包括模型输出的准确率（Accuracy）、精确率（Precision）等基础量化维度； 2. **轨迹与治理层指标（Trajectory / Governance Level）**：监控智能体在整个决策路径上的执行轨迹。重点核查智能体是否严格处于治理框架约束的"护栏"之内、在全流程中是否调用了正确版本的信息和 Prompt，以及是否发起了合法且精准的外部工具调用（Tool calls）； 3. **运营层指标（Operational Level）**：严格追踪资源消耗与经济效益，例如单次请求的资金成本（Dollars per request），确保智能体系统的持续运行符合预算边界。 Rahul 总结道，当企业决定使用前沿 AI 智能体去改造甚至彻底重构现有的核心业务系统时，必须在上述三个层面建立全方位的可观测性（Observability），只有拿出确凿的轨迹记录与成本ROI数据，才能在合规审查与企业战略层面为技术转型提供充分的合理性证明。 ### [34:18](https://www.youtube.com/watch?v=fV044e3-QdU&t=2058s) 业务导向与评估基准：警惕过度工程化 在探讨如何在企业中扩展和规模化部署智能体系统时，Simba Khadder 指出当前行业中存在一个普遍盲区：许多人急于搭建极其复杂的 Agent 架构，塞入各种高深组件，却根本没有想清楚这背后的业务目标（Business Outcome）是什么。当被问及预期成果或衡量标准时，开发者的回答往往是含糊的“先看准确率”。Simba 质问道：“到底是什么的准确率？是否有过基准线（Baseline）？”其实很多场景下，花 5 分钟做一个简单的检索增强生成（RAG）作为 Baseline 就足够验证效果，然后再去衡量引入 Agent Memory 和复杂协调机制究竟能带来多少额外业务增量。 ```mermaid flowchart TD accTitle: 智能体落地与业务价值验证流程 subgraph S1["1. 基线建立与快速验证"] A["基础 RAG / 最简原型<br/>(5分钟快速搭建)"] --> B["业务指标与嗅探测试<br/>(15个典型提问/小规模灰度)"] end subgraph S2["2. 价值衡量与决策"] B --> C{"是否达到业务要求?"} C -- "已满足需求" --> D["就地交付低垂果实<br/>(避免过度设计)"] C -- "需要进一步提升" --> E["引入复杂 Agent 架构<br/>(增加 Agent Memory / 工具链)"] end subgraph S3["3. 持续闭环与优化"] E --> F["隐式反馈追踪 & 自动化评估"] F --> G["聚类错误归因与针对性迭代"] end ``` Simba 结合自己在推荐系统（Recommender Systems）领域的机器学习背景分享道，评估系统不能单靠显式的点赞或点踩（Thumbs up / Thumbs down），而要深入挖掘隐式反馈（Implicit Feedback）。例如：用户是否重复提出了相同的问题？用户是否直接流失（Churn）了？深入理解业务问题并验证系统能否推动核心业务指标，才是决定是否要加码优化 Agent 的前提。针对 Ram Kumar Nimmakayala 提出在概率性系统（Probabilistic Systems）中评估标准不断变化、PRD 难以固定的问题，Simba 直言“别再写传统的 PRD 了”。在缺乏基准时，最实用的做法就是把最基础的原型推给一小部分用户，或者拿预先写好的 15 个问题跑一遍“嗅探测试”（Sniff Test），只要系统不至于让人出丑，就可以将其作为 Baseline，评估是否值得继续投入资源。 - **快速 Baseline**：在堆叠复杂 Agent 架构之前，先用简单 RAG 或最小原型测算业务回报。 - **隐式指标捕捉**：通过重复提问率、用户流失率和任务完成度等行为信号来量化实际解决效果。 - **避免过度投资**：企业中存在大量“低垂果实”（Low-hanging fruit），如果基础方案已经满足业务需求，便无需强行引入过度复杂的智能体栈。 --- ### [36:51](https://www.youtube.com/watch?v=fV044e3-QdU&t=2211s) 人机协同（HITL）权衡与红队对抗测试 谈及如何设计人机协同（Human-in-the-Loop, HITL）机制而不让其沦为系统吞吐的瓶颈时，Rahul Zende 提出了“越少越好”的原则。他指出，人类天然不具备高度标准化的输入习惯，如果将非标准化的人工反馈生硬地接入循环，往往无法支撑系统的规模化扩展。然而，在强监管与合规（Regulatory Compliance）要求下，某些场景必须保留人工审核；而在文档审查（Document Review）等复杂任务中，当结合 OCR 与生成式 AI 的多模态流水线无法达到预期准确率和细节层级时，引入 HITL 也是提高精度的必要手段。 在系统对抗与鲁棒性方面，Rahul 确认他们全盘引入了红队测试（Red Teaming）。测试不仅包含对抗性输入攻击（Adversarial Inputs），还重点针对工具调用（Tool Calls）的延迟（Latency）进行严苛压测。在许多需要将传统流程“智能体化”（Agentify）的系统里，若工具调用的端到端延迟超出可接受阈值，整个系统的实用性就会彻底失效。 --- ### [38:58](https://www.youtube.com/watch?v=fV044e3-QdU&t=2338s) 样本增强、合成数据与多 Agent 自动化 Debug Serg Masis 补充了在早期人类反馈数据稀缺时的应对方案。他强调必须学会“推断”（Infer）信号与“增强”（Augment）测试集： 1. **推断用户意图**：密切关注单次交互后即退出的行为信号，积极联络 Beta 测试人员进行定向访谈。 2. **利用 LLM 合成对抗数据**：挑出高质量的人类提问，利用大模型生成语意相近、逻辑一致但包含不同措辞风格的变体，甚至是带有对抗色彩的合成提问，从而在同等测试集规模下大幅扩展覆盖面。 | 评估与调试维度 | 核心做法 | 落地目的 | |:--- |:--- |:--- | | **隐式信号推断** | 追踪提问后即停、单次流失等无显式评价的行为 | 挖掘被忽视的不满与失败交互 | | **数据合成与增强** | 提取优质提问，利用 LLM 生成对抗性与多样化变体 | 解决冷启动期人工标注样本不足的困境 | | **多 Agent 故障聚类** | 引入审查 Agent 对数百条失败用例自动分类与归因 | 批量捕捉共性 Failure Modes，实现前置拦截 | 当面对 Beta 测试阶段产生的海量错误用例（例如 300 个提问中的各种异常）时，人工排查极其耗时。Serg 介绍道，他们的工程实践是部署另一个专门的分析 Agent，自动对所有出错样本进行故障分类与模式聚类（Clustering Failure Modes）。这种方式让团队能够一次性攻克某一类共性失效模式，进而在未来的迭代中实现前置检测与拦截。 --- ### [40:53](https://www.youtube.com/watch?v=fV044e3-QdU&t=2453s) 智能体框架选型标准与生产落地避坑指南 在观众问答环节，针对当前 Agent 框架的选型考量，Simba Khadder 从 SDK 开发者视角给出了专业剖析。他认为框架选型有三大核心：一是与 Agent Skills 及现有体系的集成度；二是底层性能与 Scale 能力，包括与评估体系的整合深度；三是代码的“品味”（Taste）与直觉感——优秀框架的代码在 Review 时应当让人能够迅速感知逻辑结构，降低维护与排错的心智负担。Rahul Zende 则补充强调了从企业级视角必须审视的两点：灵活的调试支持（Debugging Support）以及数据隐私与防泄漏要求（Data Privacy），对于金融等敏感机构而言，支持本地/私有化（In-house）部署是决定性条件。 在对谈尾声的快速总结中，Waqas Makhdum 为智能体投产总结了两条核心“避坑指南”： - **回归第一性原理**：不要为了追赶技术潮流而盲目做 Agent，时刻审视“为什么要做”以及“预期的业务成果是什么”。 - **打破静态评估误区**：切忌只在上线前跑一套固定的静态基准测试（Static Benchmark）就草草了事；生产环境下的 Agent 系统必须构建成能够持续学习、不断捕获线上反馈并快速迭代演进的闭环系统（Continuous Learning Cycle）。 ## Notable quotes > [00:04](https://www.youtube.com/watch?v=fV044e3-QdU&t=4s) 有多少人已经在构建多个协同工作的多智能体编排（Multi-Agent Orchestration）系统？ — Serg Masis > [02:22](https://www.youtube.com/watch?v=fV044e3-QdU&t=142s) 我个人名下大概就同时跑着至少 100 个智能体，在不久的将来，每个企业员工可能都会有上千个智能体在替他们工作。 — Simba Khadder > [06:25](https://www.youtube.com/watch?v=fV044e3-QdU&t=385s) 如果你正在构建智能体，拜托不要再做选股智能体或旅游规划智能体了，这个世界不需要更多这类东西了。 — Waqas Makhdum > [08:27](https://www.youtube.com/watch?v=fV044e3-QdU&t=507s) 如今能正常工作的智能体与失败的智能体之间，唯一的差别就在于上下文（Context）。 — Simba Khadder > [26:48](https://www.youtube.com/watch?v=fV044e3-QdU&t=1608s) 如果用最顶级的模型都做不出来，那说明当前技术条件下这件事就不可行。 — Simba Khadder > [18:10](https://www.youtube.com/watch?v=fV044e3-QdU&t=1090s) 从 A+ 跌至 D- — Waqas Makhdum > [34:18](https://www.youtube.com/watch?v=fV044e3-QdU&t=2058s) 到底是什么的准确率？是否有过基准线（Baseline）？ — Simba Khadder > [34:18](https://www.youtube.com/watch?v=fV044e3-QdU&t=2058s) 别再写传统的 PRD 了。 — Simba Khadder ## Mentioned Ram Kumar Nimmakayala, Serg Masis, Rahul Zende, Simba Khadder, Waqas Makhdum, Syngenta (先正达), Navy Federal Credit Union, Western Governors University, Redis, Nebius, Cropwise AI, Agent Blueprints, Model Context Protocol (MCP), Claude Opus, Kimi K3, OpenAI, Anthropic, Google, IBM, Revolut, OSWorld, Stanford HAI ## Video description Serg Masis - Principal AI Scientist, Syngenta Rahul Zende - Sr Principal Data Scientist, Navy Federal Credit Union Ram Kumar Nimmakayala - Principal Product Manager, AI, Western Governors University Simba Khadder - Head of AI Product, Redis Waqas Makhdum - VP of Developer Relations & Community, Nebius This panel explores the technical foundations and deployment challenges of AI agents capable of navigating real-world environments. Hear from engineers and researchers who have developed agents for enterprise workflows, robotics, and dynamic simulations. We’ll cover agent memory, goal-setting, and coordination across multiple agents, plus the systems required to evaluate and evolve them over time. Panelists will discuss real-life implementation constraints and offer practical takeaways on integrating agent-based systems into production pipelines. [Source](https://www.youtube.com/watch?v=fV044e3-QdU)

[0:04] Serg Masis: 有多少人已经在构建多个协同工作的多智能体编排（Multi-Agent Orchestration）系统？ [2:22] Simba Khadder: 我个人名下大概就同时跑着至少 100 个智能体，在不久的将来，每个企业员工可能都会有上千个智能体在替他们工作。 [6:25] Waqas Makhdum: 如果你正在构建智能体，拜托不要再做选股智能体或旅游规划智能体了，这个世界不需要更多这类东西了。 [8:27] Simba Khadder: 如今能正常工作的智能体与失败的智能体之间，唯一的差别就在于上下文（Context）。 [26:48] Simba Khadder: 如果用最顶级的模型都做不出来，那说明当前技术条件下这件事就不可行。 [18:10] Waqas Makhdum: 从 A+ 跌至 D- [34:18] Simba Khadder: 到底是什么的准确率？是否有过基准线（Baseline）？ [34:18] Simba Khadder: 别再写传统的 PRD 了。

[2:22] Serg Masís: I'm a strong believer in multimetric evaluation. [2:22] Waqas Makhdum: If you're building agents, please stop building a stock picker or a travel agent. I think the world doesn't need more of those. [8:27] Simba Khadder: The only difference between agents that work and don't work nowadays is context. [26:48] Simba Khadder: If I can't do it with Opus, it can't be done... today. [36:51] Rahul Zende: less the better

[0:04] I am here with uh four panelists. I work  for WGU. I'm a principal product manager [0:12] focusing on enterprise AI. And I'll let uh the  panelists introduce themselves. Was over to [0:19] you. Hi everyone. Wakas Maktum. I lead developer  relations and community at Nibius. We are an AI [0:26] cloud that provides all the way from GPU access  to managed inference and as well as the agentic [0:34] tooling for builders across a wide range of use  cases from like startups, AI natives, enterprises, [0:41] etc. to to build their workloads. Simba. Hey  everyone, I'm Simba Coder. I work for Reddus [0:47] that Reddus and I lead AI there. I was a  founder before came in for acquisition. [0:55] Hi everyone, I'm Rahul. I'm a senior principal  data scientist at Navy Federal Credit Union. I [1:01] sit in the enterprise AI strategy team there.  Uh and let me just say uh the number of hands [1:06] raised this year about agents in production. Ram,  great question to start that. I'm very happy to [1:12] see that this was not the case last year. Very  nice. Serge, I am Serge Mas. I'm a principal [1:19] AI scientist that's in Genta where I build  agents, build agent tooling, orchestration. Um, [1:26] and I focus a lot of on interpreting outputs,  you know, working on evaluation and that sort [1:32] of thing. Keep improving everything. Um, yeah.  And before anybody asks, this is a 3D printed [1:39] cast. I broke my my wrist. So, so sorry before you  go to questions, can I pile on to your series of [1:48] questions on agents? How many of you are actually  building multiple agents that are working together [1:54] like multi- aent orchestration and and that oh  wow that's impressive. So as you can see we have [2:03] uh panelists coming from different verticals,  different industries, different functions. [2:10] So we are trying to what we're trying to do is  we're trying to give you a real world perspective [2:15] of how how to deploy agents in production for  the next 45 minutes. So I'll quickly start off [2:22] with one question. What kind of agents are in  production today? I'll start off with surge. [2:30] Uh well uh the biggest one is cropwise AI. Uh  crop wise AI. I work in agriculture. I probably [2:36] should have said that earlier, but uh it's it's to  help farmers uh ask questions about their farms, [2:42] ask questions about crops, uh pests, and  uh you know, pretty much understand how to [2:50] uh improve the operation of their farm, whether  for sustainability reasons, financial reasons, and [2:56] so on. Um and so that's that's the main thing, but  we also have reporting agents and a bunch of other [3:03] things. Uh a lot of cool tech. um u involved uh  satellite imagy uh drones and all sorts of things. [3:11] Uh but uh yeah basically our agents are in that  realm. Share some more insights like what does [3:17] the production pipeline look like and what sort  of metrics do you guys look into? Um I'm strong [3:24] believer in multimetric evaluation. um we even  from the ML days back when I was you know building [3:31] my own training training my own models it was  really important to look them more than one matrix [3:36] so of course we're looking at accuracy but um  and accuracy have a lot of different like nuances [3:42] to it even on a per component basis as well and  uh inference speed as well uh costs um and also [3:52] length um if there retries to regenerate something  with an LM, how many retries, all sorts of things. [4:00] Um, yeah, it's it's a whole bunch of metrics.  Rahul, what is what is your take on it? I think [4:07] uh similar uh to what you've been seeing in the  financial sector. Uh I would say a lot of agents [4:16] border on the line of uh internal productivity  as a topic. uh more on that side versus more uh [4:23] less on the customerf facing side or as member  facing side as we would call it at Navy Federal. [4:28] Um having said so I think uh piggybacking on what  search said uh we also look at a lot of metrics [4:35] for agents. Uh one of the more important things  besides component level uh metrics like search [4:42] was talking uh you have accuracy etc. But we also  look at things like trajectory level metrics or [4:49] operational metrics. Um agents by themselves  uh we don't just look at them as uh tools of [4:56] accuracy and precision but we also want to see  what kind of value we're getting out of it and [5:00] how closely they're uh staying behind governance  and security thresholds that we set for them for [5:06] peak efficiency and controls. [clears throat]  Simba, anything that you want to add? Yeah, [5:11] I mean we see a wide perspective of things because  at Reddus we power a lot of our customers agents. [5:18] So I get to see what kind of everyone's doing.  What's interesting is there's the agents that [5:23] we build for customers. There's stuff that we  build to help our customers build agents and then [5:27] there's our own internal agents. We have like  an AIS surre like a lot of issues that happen [5:32] on cloud. We actually have an agent that can go  through that and it's amazing what it's able to [5:38] do. Um things like when uh we have a ton of cloud  users. Uh every time something happens or we see [5:45] a big change, we have it go through an agent to  see and try to figure out, hey, is this relevant? [5:50] Is this useful? Should someone do something about  this? Did something go wrong? So there's a lot of [5:54] internal automation that happens. Um we had this  talk once of how many agents do we think we'll run [5:59] per person? I'm probably running like at least 100  agents just for me and I can imagine in the near [6:04] future every employee will have a thousand agents  running on their behalf. Wakas, I know you manage [6:11] the AI cloud infrastructure uh for the agents.  Do you see uh do you have any numbers on top [6:17] of your mind uh like as to how many companies  are putting the agents in production today? [6:25] Um so it's a hard uh question to answer because  I feel like many of the workloads people are also [6:33] sort of calling them quote goat agents now um and  and you know we we see like Reddus we we we power [6:41] uh whole range of AI builders to go from on their  journey like some of them are building uh their [6:49] own startups like AISR or uh coding agents and  customer service agents like your packaged agents [6:55] if you will. Uh but then you'll see in enterprises  there is a wide range of experimentation for the [7:01] most part taking place. Uh like like talking to  someone they're building a revops agent. Quite [7:06] fascinating. It requires actually 10 agents to  work together. Um so we're seeing we're seeing [7:12] this this broad spectrum. Um what I was going to  say is that if you're building agents, please stop [7:18] building a stock picker or a travel agent. I  think the world doesn't need more of those. [7:23] So fantastic. Um that's um so see single um but  other than that uh there is um you know having [7:34] seen a lot of these agentic uh patterns uh we  have recently launched something called agent [7:41] blueprints and there's going to be more work on it  but the idea behind that is to come up with some [7:46] reference implementations around bucket of for  now horizontal use cases that will expand up to [7:54] vertical as well. Uh but the idea really is that  that you can build agents if you go to some of the [8:01] the two or three closed labs and their APIs, but  the world needs a like an open ecosystem and and [8:08] a stack of of open stack of of the of that brings  the the layers together for building agents. So [8:14] that's the idea behind it. I can go into the  details of why it's important but uh we are [8:19] taking those learnings and turning them into these  open reference um implementations. Y got it. So [8:27] now that we've talked about agents in production,  let's uh shift gears a little bit towards memory [8:34] context and changing states. So this question  is Mr. Simba. Um, moving an agent from a control [8:43] environment into a live enterprise workflow breaks  state assumptions. How are you designing agent [8:49] memory and goal management to survive unexpected  changes? The only difference between agents that [8:56] work and don't work nowadays is context. We  used to talk a lot about like hallucinations [9:01] and stuff. At this point, if it's hallucinating,  it probably doesn't have the right to context [9:04] and it's guessing. Like, we've kind of gotten  past the point of it just making stuff up. it's [9:09] usually actually just doing its best of what it  has. I'm at the point where if you give the right [9:14] data and context to the agent, it will be able to  solve the problem at hand. That is the fundamental [9:19] problem that everyone is trying to solve. Right  now, almost every company I talk to is trying [9:23] to solve that problem. The thing that's changed  is when people used to talk about context before [9:27] it was rag. We put a vector DB, we just grab our  docs, we index it. The problem with rag is it's [9:32] inherently linear. You're pretty much saying,  "I'm going to go get the documents up front [9:37] and then I'm going to give it to the LM." But if  you watch the coding agents, um, I mean, we could [9:41] probably start a coding agent before this talk  started. It still be running till after. If you [9:46] had given me a prompt and given me 45 minutes to  think about it in a, you know, blank white room, [9:51] I would hallucinate for sure. So, the agent's not  going to do any better. And so the idea is how do [9:56] we make it so the agent during runtime during the  reasoning loop it is able to find the context it [10:01] needs reason about about it get more context etc  and build that loop. So we need to define context [10:07] that is dynamically navigable that's always up  to date that's fresh and fast to retrieve and [10:13] compounding. When people talk about agent memory,  they oftentimes think about like Simba likes the [10:18] color red. That's great and every agent memory  solution kind of does this to some extent. But [10:23] the thing that we see that's extremely powerful  is agents becoming stateful in the way that they [10:28] remember how to solve problems like the S agent.  Oh, when I see this log, even though it might [10:33] imply this, it actually means I need to go check  that Kubernetes is doing something weird. And so [10:37] you build this procedural memory where it actually  the agent becomes stateful and smart and actually [10:42] gets better of usage. So I think that we're just  scratching the surface of what's possible and I [10:47] think everyone should be thinking of how do  I build a context engine that makes context [10:52] again dynamically navigable but compounds and so  that's what we help customers build that's what [10:56] I'm seeing people build with or without reddis  interesting sorry go ahead no finish with that no [11:03] I was going to say that's spot on um and it's it's  like that that that problem as you said is just [11:09] we're industry is scratching the surface um things  like been talking to some of the the builders that [11:15] are trying I guess they're in the enterprise  and they are trying to solve for asynchronous [11:20] uh stateful problem and essentially like you  have this fraud detection agent or agents and [11:27] um sometimes customers come back to you uh when  you raise something 4 days later. So how do you [11:32] kind of restart from where you pause the case  waiting on the input and then accurately go there [11:39] without burning the tokens and kind of starting  over the workflow which has been happening in [11:43] the vanilla state right the other interesting  problem that I I I think that there's going to [11:48] become more predominant is around how the agentto  agent context pass through and all of that stuff's [11:54] going to happen too so quite fascinating space any  contrasting perspective search that you want to [12:01] Well, not really. I I I agree with them completely  on that. I I think it is it is paramount to to [12:08] keep context. Um as as important as it is, it's a  well, it's the most important thing for an agent. [12:16] So I the only thing I would add and it's not  really a contrast is that there is such a thing as [12:22] too much context and and that's where things get  lost. So you have to do quite a bit. Like in in [12:27] my line of work, it's really possible to get like  it's it's not that the the context was wrong. It's [12:34] just that it was so much for the agent to process.  It processed the wrong parts. So it gives back a [12:39] response that is technically correct, but a human  interpreter would say, well, this is not quite [12:45] what I was looking for. You know, like it gave  me, say it asked for, you know, what uh you know, [12:51] what pest does this fungicide serve? and it it  might be a thousand and it it happened to sort [12:58] them alphabetically in the context. So it got like  the first, you know, 10 and that's what it said, [13:03] but the first 10 are not really the most important  ones, right? So that's that's the sort of thing [13:08] that happens and and so we have to get really  good at refining that context to what really [13:13] is relevant to the user. So Rahul, both of us  operate in a regulated environment. Uh you're [13:20] in financial and I'm in education. So where do you  think the contest rot starts first? Uh I think u [13:28] you really h need to have a tight control on u  how your agents are managing states. I feel like [13:35] uh memory management and Simba correct me if I'm  wrong. U memory we talk about memory management [13:41] for agents as a single monolith. That should not  really be the case. I feel like the states uh that [13:47] you're having your agents go through that's really  where rot I I find them happening not managing [13:53] those properly u you have a lot of issues like the  example he gave if you have an agent that keeps [13:59] running for some time if it has to do back flips  and come back to the previous points uh retracing [14:06] that will not be easy um what Serge was saying  um that brought an analogy to mind um it's like [14:13] um I when I was a student myself, I studied  computer architecture. Uh cache memory and RAM [14:20] memory are probably very similar analogies to  what we're talking about here. You you can you [14:25] can technically make the cache memory very large,  but that would not solve the problem or that would [14:29] create more problems by itself. I I think that  the the root of the problems are stored in there [14:34] somewhere. So um quickly moving to the next topic,  you know, I think it's a good segue. We talked [14:41] about agents in production. when we talked about  memory context management. Now let's talk about [14:46] the orchestration multi-agent um uh orchestration  especially I know single agents are hard but [14:52] uh when when there is a lot of coordination that  needs to happen between multi- aents like let's [14:58] get little bit more technical um and understand  like what kind of orchestration frameworks do you [15:03] guys use at your respective companies anything  that you wanted to share a little bit more [15:08] about the protocols uh especially in production  space I'll start with uh Vakas Cool. Um yeah, [15:15] I mean as my take is that that a lot of the multi-  aent orchestration world is still in its academic [15:23] phase. So you see a lot of research papers but um  there there's a lot of work that I would say early [15:28] stage startups are doing that is very aspirational  but at the end of the day you don't see a lot of [15:34] that actually seeing the the real world yet.  And um just speaking on the the advancements [15:39] in orchestration. I mean you you look at this this  problem in the I would say in different buckets. [15:46] I mean all the way go from like like how the task  decomposition and task breakdown happens for for [15:52] an agent and then it gets assigned to the sub  agent swarm. Um there u you know that that that [15:59] whole problem space does as far as I know there  isn't really a predominant um standard yet. And [16:06] and the goal for these frameworks is really not to  hook you up on a certain tooling is to really give [16:12] you the primitives that that across across the  uh the your organization and and systems you can [16:20] um uh you you can you can standardize on and  use. So that there's one one bucket of that. [16:25] The second bucket I think is more around this  context pass through world that also does not [16:30] have much of um standardization. And a lot of  the stuff is happening with JSON outputs and um [16:37] that's where we're seeing a lot of enter complex  semicomplex enterprise use cases breaking because [16:43] um you know schema changes happen and the the  legacy system of records etc are not ready to [16:49] to to pass on the the exact right information  to the agents. Then you have I feel like where [16:54] actually is semi- successful is now when you do  the tool calling stuff and MCP really took what [17:00] 18 or 12 18 months to really uh become a standard  and and I know there's a lot of it's a very um uh [17:10] it it's very controversial like you know some  people love and there's love and hate around uh [17:15] MCP but uh it really is is is gotten the adoption  uh and then you go all the way down to then agent [17:21] to what we call like agent um handover like task  delegation delegation type uh handover Google was [17:29] it Google or someone attempted like A2A I think  IBM had some standards uh for the most part it's [17:35] really in the academic and research papers and  some labs doing some experimentation with it [17:40] um and then all of that all of that comes down to  actually what do you do with the outputs and and [17:44] results of that and that's always very custom and  and no standards there um so I would say that and [17:50] then if you look at uh the um I would say the the  the frontier labs um open anthropic I mean they're [17:56] taking a very SDK-esque approach so very pretty  early but they're taking an SDK type approach [18:01] uh model to go solve for how to handle multiple  agents or swarm of agents whereas yeah yes I want [18:10] to challenge you a little bit uh recently I saw a  report from Stanford hi they mentioned uh OS world [18:17] um last year production agents were  around like 12%. Now they are saying [18:22] uh 66% something like that. So what you just  mentioned like you know conceptual I feel like [18:28] there's a different reality. So I'm I'm curious  to understand like if you guys are seeing the [18:33] same thing or is it like or or or the the the  sample results are like a little bit biased. [18:40] I think I mean if we're talking multi- aent  systems I there's no way that there's 66 I've [18:45] see I've talked to almost every bank in the world  and there's no way that there's 66% of adoption of [18:51] multi-agent system single agent systems maybe but  definitely not multi- aent I also find that no one [18:56] has got it to work multi-agent systems inherently  the thing that doesn't work is the architecture [19:00] everyone tries which is an orchestrator agent  with a ton of sub agents everyone tries this I've [19:05] never seen it actually work with high accuracy in  fact if you look at uh cloud code and all these [19:10] services, they all have a multi- aent system,  they're all marked as u alpha and they're all [19:16] marked off by default because even at that level  with all of that data and all of that scale, [19:21] they're unable to get it to work. what  we've seen actually work. Like for example, [19:26] we work with a company and their problem is it's a  large airline and their problem is that they have [19:31] all these teams and each team has an agent and  now they have the problem where their app has like [19:34] 15 different screens with like different agents  that you talk to and none of them know anything [19:38] about each other and there's a bit of like a  political fight because no one wants to, you know, [19:42] everyone wants to be that oh we'll be the the or  the orchestrator agent and you guys will all be [19:46] like kind of sub agents of my agent. And so what  we ended up doing and helping them solve which was [19:51] both highly accurate and worked really well was  we put a semantic router. So we have a product at [19:56] Reddus called intent router which is part of our  Iris stack. And what intent router does is they [20:00] pretty much would define these intents and they  would have examples for every single intent of [20:04] like here are questions that should go this agent.  Here are questions that go to this agent. Now, the [20:07] interesting thing was is you might be talking to  a different agent on every turn and you wouldn't [20:12] even know because the only difference really is  just the system prompt and the set of tools. And [20:16] so, you're pretty much plugging in a different  system prompt and set of tools on every single [20:19] iteration. That's what we've seen actually work. I  actually think that is currently the bar of where [20:25] agents and LLM are right now. It will change like  next year it's going to work, but right now that's [20:30] I think where where we're at. Yeah. Sorry, I was  just going to add to this that in in one of the [20:37] uh cases we're working with a native company and  they realized that a lot of the single agent task [20:43] completion rates were over 95%. Um but then when  you compound that to 10 15 agents, you're looking [20:50] at like 60% workflow success rate. So it's kind  of like goes from a A+ to D minus very quickly. [20:56] So that's where I think that a lot of the in a  lot of the cases people are are hardwiring the [21:01] the task handoffs as as uh Simba mentioned and um  yeah so u Rahul in your regulated environment how [21:11] do you handle the drift especially when you have  multi- agent orchestration right like and we talk [21:16] about the loops we talk about the the states right  so how do you manage that and and especially when [21:21] you have a a financial ramification like how  do you handle that I think yeah auditory and [21:28] traceability concerns are very much paramount u in  my capacity I strongly this might come across as a [21:35] lite perspective but I personally advise people  against setting up multi- aent systems unless [21:41] absolutely necessary I mean the sheer overhead of  cost latency etc is is just very hard to justify [21:50] unless we come across a positive justification of  that leaving any positive gain in lift in metrics [21:58] behind it after the implementation, we we strongly  work against it. Having said so, yes, uh I I don't [22:05] think um as a credit union, we are not in the  business of setting up systems that do this at [22:10] the most granular level. We would uh want to want  to think about services and platforms that let us [22:16] do this inherently to the best of their capacity.  Uh I don't think we are quite there yet. uh for [22:21] multi- aent systems to be truly as interpretable  and as uh as auditorially transparent uh to be [22:30] implemented across the board. Hold your thought  there. I think we'll definitely get into that [22:34] part. Uh Serge, I want to hear your perspective  here uh especially coming from a agricultural [22:40] industry. Yeah, I I I agree with all of them. I  I don't really see that many multi-agent systems. [22:47] I think uh the agent of course it's called agent  because it has agency and that comes from having [22:53] that ability to you know create the next step  the next thing whatever it is right and whether [22:59] that's an output or whether that's a you know  okay I'm going to use this tool or something [23:04] else there's something that workflow that that  creates that dynamism that that stochastic [23:10] uh but my reality I I I urge people to to to take  make things as determin istic as possible. Sure. [23:19] To to achieve the goals they desire, right? And  and and only use the the agents agency in in areas [23:28] where it's really necessary. Of course, when you  add multiple agents, you're just compounding upon [23:33] that, right? and and and honestly a lot of systems  don't require it you know like when we have like [23:38] a reporting agent you know it there's a very  deterministic workflow there really the reporting [23:44] agent is deciding okay how do I take this data  and create the report it's it's not much more [23:49] complicated than that right um and so and and for  other things I actually the most I ever do is take [23:56] a tool and and create somewhat of a pseudo agent  with it and what I mean is I I hide the context of [24:02] that tool and just because it's not necessary for  the agent to to answer the question right what I'm [24:09] understanding is do you also see the value of uh  automation like RPA along with agentic AI or uh uh [24:17] I mean especially for um simpler task can you can  you use like deterministic models of course we we [24:25] do that all the time I mean we we have like before  I was working in classical machine learning and [24:32] we've we have a large catalog of machine learning  models. And if if a user wants to, you know, uh [24:40] predict if they're going to have a certain pest,  a user, a farmer, within the next uh you know, [24:45] within the season or the next few weeks, we can  predict that with traditional machine learning. [24:50] And really much what the agent is doing is using  that tool, getting that data and outputting it to [24:54] the user, right? So it makes the job a lot easier  to have that tool there for that. they're not [25:02] just, you know, coming up out of that out of thin  air. That would be very silly. Um and um yeah, [25:10] as as far as that goes, I I think there's also  something pretty interesting about agriculture, [25:17] which is that uh basically it's it's a human  activity that takes up what is it like 30 38 39% [25:26] of the of all our land, all the the earth's land,  right? And uh and that that includes grazing which [25:34] is the vast majority of that you know actually  crop land is like 10%. And uh it employs 26% [25:41] of of humans and then uh it represents between 4  and 10% of GDP of the world. Yet if I take an open [25:50] data set right that is used for training models  right it's somewhere around 0.5 0.7% of all the [25:58] documents in that corpus right and that's only  open data sets if we we go to closed data sets [26:03] I'm pretty sure it's far less because they're  using copyright material that has nothing to do [26:08] with agriculture and a bunch of other stuff you  know Reddit and whatnot there's very little about [26:13] agriculture there so I I think in general when  we're trusting these foundational models to to [26:19] uh create outputs about our domain. There's a  lot of stuff because it's underrepresented. It's [26:25] not going to make sense, right? So providing  the right context, evaluating it correctly, [26:30] uh creating this deterministic workflow where  we actually be evaluation first that that's the [26:37] right right procedure in a domain like ours. you  know, maybe using the foundation model strictly as [26:43] it is is is okay in another industry like media  or something, but it's definitely not in ours. [26:48] Do you guys see uh the potential of uh open source  models uh in the space? Simba, go ahead. You Yeah, [26:58] I mean I'm sure you have a ton. Yeah, I was going  to say I mean NBS you guys surely have a lot of [27:03] thoughts about this. Um our take is this. We  always start with everything with the foundation [27:07] models. The idea is if I can't do it with Opus,  it can't be done like today. That's kind of my [27:14] view. So the idea is let's get it to work here.  That will help us build an eval set. It will help [27:18] us show business ROI. It'll help us even prove  what are we even trying to do here and what's [27:22] architecture need to look like. Once we're there,  we start thinking about scale. And once we think [27:27] about scale, we want to own the the nines. We  want to own all that stuff. That's when we start [27:31] thinking about how do we leverage all the open  weight open source models are really really good. [27:36] are not quite as good, but they're not far behind.  And the idea is like for most things, you don't [27:41] actually need all that extra bit. Once you have it  working and you have an eval loop and you are able [27:46] to fine-tune and get exactly what you need, you  can get these open models to be just as good. Um, [27:50] you can sometimes even get much smaller models  to be just as good. And so once we move for that, [27:54] we kind of start moving to open weight and open  source models. And our view is that most models [27:59] in the future will just be open social open except  for the hardest set of problems. I know you got [28:04] super excited. Yeah, I have a lot of thoughts  and I we don't we're short on time but I was [28:08] just basically uh say that the world the paradigm  is shifting as you all know because there used [28:14] to be a thought that you know the the the open  source/Chinese models would be mostly distilled [28:19] version of the frontier foundation model but like  with Kimmy K3 for example came out I'm not saying [28:24] they didn't distill but it actually is a real  like real true model that that you know like was [28:31] basically uh giving a fable and others for the run  for the money what what I was going to go taking [28:37] back the conversation to uh the agent tech uh use  cases I do feel that as you build the harness for [28:44] the agents you have to have you keep the the  models have to be swappable in a way that you [28:48] build it and that's the the way to sort of like  architecturally um built towards scale when when [28:55] you when you go with it. So uh we're seeing a ton  of uh um customers like one customer uh revolute [29:03] for example they're building that uh fraud uh uh  detection per profile use cases obviously started [29:10] a lot of them start on the found on the frontier  models but then as soon as you see the cost that's [29:16] one factor obviously but then the other factor  interestingly that is emerging for agents is that [29:23] the agentic use case does not have that much  of sensitivity to latency for the most part, [29:29] right? So, if a task is is a longunning task  that takes 10 minutes or whatever an hour, [29:33] you can add a little bit more latency to it and  really do creative things to bring your cost down [29:38] by sometimes by like, you know, 80 90% down. Um  and um you can do things like you know like like [29:45] you you can run a lot of your um um workload on  like you can do up to like 95% KV cache so you [29:53] don't like really hit your GPUs uh and and and  do other techniques there. So there's a whole [29:58] bunch of things besides the philosophical  reasons of open weights models to to to go [30:02] for agents. Yeah. Just uh for in the interest of  the time let's shift gears towards uh evaluating [30:08] agents. I know traditional models evaluating  traditional models is straightforward but when [30:13] you talk about evaluating agents especially  in the multi- uh agentic orchestration world [30:19] um what sort of metrics do you guys look  into uh I'll start with search uh search [30:24] like what sort of metrics do you guys look  into and how are you handling that today? [30:29] Yeah. Uh when I came from uh you know ML, you know  I my thought process about this was wrong, right? [30:37] Uh because basically in ML you you start with the  data and then you move forward and you just build [30:43] whatever you need to build. Of course there's  product considerations there but it generally [30:47] works like that. If you have data available  and you know what you're trying to predict, [30:51] you build it, right? Um and and and you have the  data to you know of course to to uh evaluate it. [30:58] uh from the get-go, but um I I thought uh you  know because AI is going backwards from the [31:06] product that everything was backwards. But it  turns out that you do need you know your your [31:12] your golden data sets from day one and and getting  getting that in in a domain like ours can be hard [31:18] because you you have to ask experts for their time  to come up with these things. So now I I'm we're [31:24] very strict. We we we need that golden data set  or where the product doesn't get done, you know, [31:28] we we we work away from there from evaluation  to configuration, right? So it it becomes, [31:36] you know, a test-driven development uh you know,  configuration driven development backwards, [31:41] right? Um and and that's that's how we think  about it. Of course, they have to label all these [31:45] things. And at at a basic level, it has to be  labeled. It can't be just oh this is wrong, this [31:51] is right. It has to be descriptive. It can't be  because otherwise we're just testing like end to [31:56] end and we want to test a little bit deeper than  that. So we want to know what's wrong about it. [32:01] Then we can we can probably go from there and and  figure out why it was wrong and then label things [32:06] within the components, right? Uh but we need that  initial like um push from domain expertise. Yeah, [32:15] I think we have 13 more minutes. So so let's try  to wrap up uh quickly on this topic. uh Rahul [32:22] uh in the compliance world right like I understand  interpretability is super critical just throw some [32:28] light uh from that perspective like especially in  the production world like how do you handle that [32:33] and any uh insights that you want to share with  the people can you repeat the first part please [32:38] uh the compliance aspect uh you were talking  about the interpretability earlier so I wanted [32:43] to hear that perspective here I think uh yeah  u this goes back at the metrics conversation we [32:49] were just having uh we we have metrics defined  uh as a sort of three layer cake you can say [32:56] uh making agentic systems interpretable means you  need to have metrics at the component level then [33:02] uh examples of component level metrics would  be your standard accuracy uh etc precision uh [33:09] but you would also look for uh metrics at the  operational and the trajectory level levels or [33:14] layers uh what I mean by trajectory level is you  would look uh to see if the proper governance [33:21] mechanisms are something that the agents uh stay  behind. Uh do they uh follow the right uh versions [33:28] of information prompts etc that need to be uh used  along the along the flow of the agent workflows uh [33:35] even the tool calls are they using the right tool  calls etc. And then finally at the operational [33:40] level uh you would you would want to see if uh the  right number of uh dollars uh per per request are [33:48] something that the agentic systems are staying  behind. uh this doesn't feed very well into the [33:54] uh question you asked about interpretability but  I think it it it hits closely to what we consider [33:59] the bottom line if if we want to justify uh  overhauling or uh changing existing systems [34:06] and workflows using AI and agentic systems uh we  do want to be tracking these things very closely [34:12] and see if they're observable at the levels  that we want them to be in order to justify [34:18] moving forward and increasing the scale of these  systems across the enterprise. Simba, uh any any [34:24] perspective that you want to share here? Yeah,  this is so the thing this is like a time to be [34:31] uh honest with yourselves because I see a lot of  people who are like, I'm going to build a super [34:35] complicated agent stack and I'm going to put  all these things inside of it. I'm like, great, [34:38] what's the business outcome we're looking for? I  don't know yet. How are we going to measure it? [34:43] Uh well, like we'll get there. We're just looking  at accuracy. I'm like, accuracy of what? What does [34:46] that mean? Like so and do we have a baseline?  Like have we just tried rag? We could do rag [34:51] in five minutes. Have we tried that and seen  you know what the outcome is and how much more [34:56] outcome would we get when we add agent memory  and do all the other stuff that we provide and [35:00] sometimes I feel like I'm actually helping our  customers even just think about how do we show [35:04] business value here. I came from an ML background  too. I was more in recommener system land and [35:08] yeah like it's there it's it's I had to learn a  lot about how to use implicit feedback like how [35:13] can we without someone having to give a thumbs  up thumbs down. How can we kind of tell if it's [35:17] actually solving the problem at hand? Did they  come back and ask the same question? Did they you [35:22] know like have to go and did they turn? Did you  know there's all these things that we can look at [35:26] and I think really thinking deeply about what is  the business problem that we are trying to solve. [35:30] How can we show that we can even move that number  at all and then let's double down on optimizing [35:36] this this agent and making it better. So given  given the importance of eval right especially [35:41] uh when we are dealing with this proistic systems  uh so from product standpoint I definitely know [35:46] that eval are going to be the critical component  of the PRDS now but how do you guys deal with uh [35:53] the eval like you know when you don't understand  the baseline today uh and and these eval keep [35:58] changing as well right like so I'm I'm curious to  understand like uh your perspective Simba there [36:03] um I think so one don't do PRDS anymore or beyond  that we can do better. Um but to um with evals um [36:11] the way to think start with what is the business  outcome and how can we measure. So if you don't [36:16] have one then put out the most basic thing in  the world and let's just see how it does. Put [36:21] on a subset of users. Most people start the really  basic way which is hey I'm going to go ask it 15 [36:25] questions I wrote down and see if it does a good  job. That's actually fine. Just a quick sniff test [36:29] of like hey does this thing completely stupid?  Um but that's not done. But just like uh it's [36:34] good enough that if I put it out into the world,  I won't be completely embarrassed by it. Then it's [36:38] like great, let's draw a baseline here and figure  out if we should invest in this thing. Maybe it's [36:43] good enough. Maybe we don't need to invest anymore  in this thing. It's actually solving the problem [36:46] enough and there's plenty of lowhanging fruit  across every enterprise right now to solve. Yeah. [36:51] One one other question. So how do you guys design  the human in the loop especially when you don't [36:55] want it to be a bottleneck? Uh Rahul, uh your  thoughts here? Um I think uh less the better. [37:02] uh given given what we want to achieve with  agentic systems uh we we try to follow the [37:08] approach of uh test and learn uh you you see if if  uh feedback from uh humans in the loop is actually [37:15] helpful there there's a the problem with human  in loop is many times um humans by default don't [37:23] provide inputs that are standardized by nature.  So making humans part of the loop does not always [37:30] help agentic systems because you can't really have  it scale in standardized to that extent. Having [37:35] said so yes uh I I think uh there are coming from  a world of regulatory compliance requirements. [37:42] there is uh there is a specific set of use cases  that you definitely want humans in the loop and [37:47] there's a other side which doesn't necessitate  having humans in the loop but then many times [37:53] you have problems with um accuracy or level of  detail that uh AI can see a good example would [38:01] be document review use cases many times we have  uh models uh that use both OCR or I should say [38:09] services uh services that use both OCR as well as  geni to look at documents and then come back with [38:14] information doesn't always meet the expectations.  Those those are the kinds of systems which we [38:19] would definitely want to see if a human in the  loop improves uh the system. Do you do you use any [38:24] red teaming or adversarial meth methods? 100% yes.  Uh adversarial inputs um also uh trying to play [38:32] around with tool calls to see if there's latency.  Many of the systems we would want to uh put in [38:39] agentic parts or or agentify systems as a whole.  We want the latency to be at a certain point [38:46] otherwise it doesn't make sense. So yes, all of  that is part of red teaming, specifically latency [38:52] and then adversarial inputs. Serge, anything that  you want to add? Yeah, um I I think I think uh I I [38:59] agree with them. The only thing I would add would  be um I think it is important as as as valuable as [39:06] human input is it it also can be scarce especially  at the beginning. So it is important to augment [39:13] and uh in any way you can and also infer. So by  infer I mean okay things like signals like Simba [39:22] said like did they ask one question and then stop  asking right that's a signal. Um even if they put [39:29] a thumbs down or or maybe they even didn't you  know that's a signal that you you have to watch [39:34] out for why. you can always reach out to them and  ask them if if they're a beta tester, if they're [39:39] there's someone already involved in the process.  And then the the other thing would be by augment [39:45] is if there's some really good questions that you  find, you can definitely use an LLM to augment and [39:50] create similar questions and uh you know make them  a mix them up, make them a little bit adversarial. [39:56] Um you know maybe along the same lines, the same  kind of thought process, the same kind of verbiage [40:02] but slightly different, right? Um and and that  that helps too because it it also creates other [40:07] ways of testing within the same kind of um human  generated process if you will. synthetic synthetic [40:16] and and that's another thing synthetic is also  important like when you when you have uh uh have [40:22] to debug something it it it becomes kind of hard  like say you have like beta testers and you have [40:28] like 300 questions they asked you know how do you  debug all the ones that were wrong right you you [40:34] um what we do is we we we just have another  agent go through them and tell us classify you [40:40] know what went wrong in each one of them how  do we cluster them so we can tag tackle more [40:44] than one failure mode at a time. Once you get a  sense of these failure modes, you can detect them [40:49] before beforehand. Yeah. In the interest of the  time, I think let's leave it to the uh give it to [40:53] the audience. Do you guys have any questions? Uh  I'll take three questions probably. The question [40:58] is about like what kind of frameworks uh are being  relevant today. Yeah. Yeah. I can I can So, this [41:05] is a really good question. Um it's really funny  because I've like it's one of those things I've [41:09] never really like deeply thought about because  it's like a nagging thought because I build SDKs. [41:12] So I have to design these SDKs and people come to  me all the time like why do we even care anymore [41:16] like we're not no one's going to look at it. Um so  one is like making sure that everything we do like [41:21] it's also how integrated is it like do they have  agent skills is it easy to use this framework with [41:27] our agentic systems is one piece two is really  about scale uh in terms of like how fast is it uh [41:34] do we have proper eval in integrations so there is  some decision- making that happens I still believe [41:40] that the there's something about like the taste of  a framework if that makes sense where if I look at [41:46] the code I feel like if something's wrong things  will go wrong. If I have to code review something, [41:50] I can feel when something feels natural for me  to quickly understand and when it doesn't. So, [41:54] I still think taste matters, but yeah, I mean to  some extent it's not what it used to be. Uh, one [41:59] more thing I would like to add, Ram. Uh, please go  ahead. The other few considerations you would have [42:04] in mind is support. How much support do you have  for that framework uh from a debugging perspective [42:09] and flexibility perspective? And one more is data  privacy. I think you saw that coming from where I [42:14] work. uh if you can have an implementation that  is in-house that doesn't have problems of data [42:18] leakage etc that would be one more thing  to decide based on so we have 30 seconds I [42:23] just wanted to ask Vakas one question so what is  one trap that you would avoid or what you would [42:28] uh advise when someone is trying to put an agent  into production okay 21 seconds now but I think [42:35] one goes back to what Simba was saying about  like stepping back first principles why are [42:39] you even building this agent what's the outcome  expected and kind of going from there second I've [42:44] seen seen a lot of uh folks developers they're  building agents and they do the the first sort [42:49] of eval benchmark that is static and then just go  with it pre-launch uh and I think that needs to be [42:54] kind of evolved into this continuous learning  cycle that you have to keep on learning and [42:59] iterating and building on top of and and that's  the yeah that's the TLDDR happy to talk to talk [43:04] more about it separately sorry guys we're out of  time and I hope you guys enjoyed this session and [43:10] got something out of it I appreciate the time and  effort here. Thanks once again, guys. [applause]