Columbia's Chun Faults Unrefereed AI Loops as 94% of Pilots Fail

94%试点告败，哥大Chun归咎于缺乏裁判机制的AI循环 企业若部署不受约束的前沿模型，而非由提交前裁判验证层管控的有界微智能体，AI智能体将无法产生回报。 面对94%的企业AI项目未能带来预期投资回报率（ROI）的严峻现实，David Chun解释了为何在生产工作流中部署如开箱即用聊天机器人等不受约束的前沿模型必然以失败告终。Chun告诫企业切勿构建难以维护的“超级智能体”，并主张采用专业化的微智能体，通过严密的循环工程、严格的上下文隔离以及在行动执行前进行验证的二级裁判层进行治理。通过其VECTOR框架，他展示了如何平衡Token经济性、ISO人机协同合规性与务实的分层模型策略。归根结底，将智能体循环约束为离散、可观察的步骤，可使企业在绝大多数业务任务中安全地部署高性价比的开源模型。 MIT最近的一项研究显示，94%获得资金支持的AI项目未能实现预期的投资回报率，且近50%的项目在上线前缺乏明确界定的业务目标。 (0:04) 部署开箱即用的大语言模型犹如雇佣了一位缺乏业务判断力的博学实习生；必须依靠严格的上下文工程来防止数据污染和规则遗忘。 (6:07) 企业应避免采用单体式“超级智能体”，转而采用在清晰编排协议下管理离散子任务的专业化微智能体。 (8:54) 循环工程和专用裁判层对于在生产环境中审查决策、落实安全护栏以及在操作执行前实施拦截至关重要。 (8:54) VECTOR框架在价值、上下文控制、测试、裁判机制及运营KPI等维度建立了Token纪律与系统化评估标准。 (12:02)

David Chun argues that enterprise AI agent initiatives overwhelmingly fail because organizations deploy unconstrained, expensive frontier models without operational structure. Achieving sustainable return on investment requires shifting away from monolithic chatbots toward specialized micro-agents governed by loop engineering, supervisory referee layers, and strict token economics. The Enterprise Pilot Trap and Context Blindness (0:04) Chun cites a recent MIT study showing that 94% of funded AI initiatives fail to deliver expected ROI, with roughly 50% failing to define operational goals before rollout. Under executive pressure to adopt cutting-edge models, organizations routinely spend upwards of $1.5 million licensing frontier tools across the workforce. Yet these broad deployments typically fizzle within two months because general-purpose chatbots cannot navigate nuanced business workflows without domain-specific integration. Chun compares out-of-the-box language models to brilliant savant interns who have memorized vast datasets but lack organizational judgment. Without context engineering to segregate private data and enforce explicit guardrails, models cannot distinguish between confidential nuances and public facts. In one university admissions deployment, an unmonitored agent operated for three months before administrators discovered it was assuring prospective applicants that a failing grade or a "D average" was completely acceptable for admission to Columbia University. Micro-Agent Orchestration and Loop Engineering (8:54) Rather than constructing monolithic "mega-agents" to handle broad executive or programming roles, Chun recommends building specialized micro-agents restricted to three or four discrete sub-tasks. Monolithic models lack native executive function, making complex systems nearly impossible to debug, audit, or align with human governance and ISO compliance standards. To ensure reliability, development must shift from basic prompt engineering to loop engineering. Systems should manage an observable cycle: ingesting inputs, inspecting authorized context, proposing actions, and evaluating outcomes. Constraining agent loops to short, monitorable sequences—such as five bounded execution steps—significantly mitigates hallucination risks and prevents long-tail drift where agents forget foundational instructions. Referee Layers and Pre-Commit Production Governance (17:27) While international safety accreditations like ISO standards mandate keeping humans in the loop, Chun notes that manually inspecting every single agent operation is physically impossible at production scale. To bridge this gap without letting autonomous agents execute unchecked actions, architectures require a dedicated supervisory tier comprising monitoring agents and semantic referee layers. This referee framework serves as an automated pre-commit gate before any agent alters production data or issues public statements. The layer intercepts proposed actions, checks them against organizational policies, and either approves execution or escalates non-deterministic and anomalous edge cases to human subject-matter experts. This prevents catastrophic runtime errors, such as incidents at major tech firms where unrefereed autonomous agents inadvertently deleted critical datasets. Token Economics and Pragmatic Model Tiering (12:02) A pervasive issue in enterprise implementations is unchecked resource consumption, such as employees utilizing costly frontier reasoning models for trivial tasks. While risk-averse institutions often consider large multi-agent swarms where dozens of sub-agents continuously cross-validate outputs, Chun warns that compounding inference costs can rapidly destroy operational ROI. To balance safety against cost, Chun introduces the VECTOR evaluation framework—focusing on Value proposition, Context and token control, Testing and orchestration, Refereeing, and Operational KPIs. He emphasizes that high-cost proprietary models are unnecessary for bounded tasks. By deploying lightweight or open-source alternatives (such as Kimi models used by DoorDash), organizations can successfully automate roughly 90% of enterprise workflows at a fraction of the cost, provided the execution loops remain tightly constrained. Chun advises organizations to focus AI agent development directly on painful operational bottlenecks unaddressed by commercial software, rather than continuously chasing frontier model releases. However, enterprise deployment faces an enduring structural challenge: fully eliminating non-deterministic edge-case failures without incurring the prohibitive token costs of extensive multi-agent verification networks.

David Chun在Ai4会议上指出，盲目采购前沿模型和部署缺乏清晰目标的“巨型智能体”是导致企业AI项目高失败率的主因；组织必须转向由上下文工程、循环工程、独立裁判层与严格Token经济学构成的结构化架构。 试点困境与高失败率成因 (0:04) 根据Chun引用的MIT研究数据，高达94%的AI项目未能在出资利益相关者眼中达成预期的投资回报率，其中约50%的项目在启动阶段甚至未定义明确的运营目标。企业高管在董事会与管理层的压力下，常将AI部署视作军备竞赛，斥巨资进行广泛授权。例如某机构花费150万美元采购前沿大语言模型工具，但在缺乏具体任务自动化的前提下，多数员工仅将其用于生成趣味图片或整理个人日历等琐碎工作，导致整个试点在两个月内便因无法融入实际业务流程而陷入停滞。 上下文工程与边界隔离防护 (6:07) Chun将开箱即用的大语言模型比作“学者型实习生”：虽然博览群书但毫无实操经验与组织判断力。若直接将其置于核心业务岗位且不设边界，模型无法区分机密内部逻辑与公开发布内容。例如在大学招生场景中，未经严格上下文隔离的智能体因抓取了底层原始数据，向咨询者确认化学成绩不合格亦可被录取，引发严重声誉事故；在另一真实案例中，某个缺乏有效监控的招生智能体连续运行三个月，持续向申请者宣称D平均绩点即可进入Columbia University。此外，系统在长期摄入合成数据后还会出现遗忘初始规则的漂移现象，必须依靠严格的知识隔离加以约束。 循环工程与独立裁判层架构 (8:54) 针对模型在复杂任务中执行漂移和丢失核心目标的问题，Chun坚决反对构建试图取代完整岗位的单体“巨型智能体”，主张开发仅负责三至四个离散子任务的微型智能体。为防止智能体越权导致灾难性后果（如科技企业中智能体误删关键数据库），企业必须超越提示词工程，转向包含输入、上下文检索、行动提议与执行校验的“循环工程”。在生产环境提交动作前，系统必须通过独立的次级监控智能体与裁判层（Referee Layer）进行语义拦截与预提交验证（Pre-Commit Validation），在不可行对全量操作进行人工复核的现实下满足ISO等AI安全合规标准。 VECTOR框架与Token经济学平衡 (12:02) 为摆脱对外部供应商黑盒方案的盲目信任，Chun提出了VECTOR评估框架，涵盖价值主张、上下文与Token控制、测试与编排、裁判与护栏，以及运营KPI五大维度。在多智能体系统（如5x5架构）中，相互交叉校验的网络会导致Token与推理成本呈几何级数增长。高风险承受力机构虽倾向于部署庞大集群相互质检，但必须从业务产出的ROI出发权衡成本。Chun建议实施模型分级策略：企业无需在每个环节都使用昂贵的专有推理模型，在受限的多步循环中，约90%的日常任务均可由Kimi等开源模型胜任，从而在抑制幻觉的同时实现成本控制。 构建企业级AI智能体的核心挑战在于非确定性输出与工程确定性之间的矛盾。未来的关键未决问题在于：在企业规模化推进自动化时，如何在符合ISO人机协同合规要求与避免全量人工审核的高昂成本之间取得长期平衡。

## Background 本内容由 YouTube 频道 Ai4 于 2026 年 8 月 18 日发布，主讲人为哥伦比亚大学研究员 David Chun。视频聚焦于企业 AI Agent 从原型走向生产环境时面临的落地鸿沟，探讨如何通过上下文窗口与 Token 优化、编排、循环工程、裁判控制层及 LLMOps 提升系统的可靠性、可观测性与业务价值。 ## TL;DR David Chun 剖析了高达 94% 的 AI 试点项目未能达成预期 ROI 的根本原因，将大语言模型形象比作知识渊博却缺乏实战经验的“天才学者型实习生”，警示企业切忌盲目构建全知全能的超级 Agent。他提出了破局的五大工程支柱与 VECTOR 框架，主张通过精细的上下文工程、任务拆解编排、限制步数的循环工程（Loop Engineering）以及外部“裁判系统”（Referee System）来解决模型缺乏执行功能和幻觉的问题。同时，他强调必须严控 Token 预算纪律，结合开源生态与业务风险分级，在关键动作提交前引入校验机制与人机协同（Human-in-the-loop），以实现真正兼顾合规与生产力的 Agent 规模化落地。 ## Atmosphere & style 演讲风格务实幽默且直击痛点，主讲人开篇即打消了观众对“魔术杂技式 AI 演示”的幻想，以清醒犀利的行业洞察直面董事会焦虑与被动军备竞赛。整场分享节奏明快、案例鲜活，从高校招生的真实事故到亚马逊生产灾难的流传，既有极接地气的隐喻吐槽，又有极具严谨度的架构推演与现场硬核问答。现场互动热烈而真诚，传递出一种拒绝虚浮炒作、回归工程本质与成本理性的技术清醒感。 ## Key takeaways - [00:04](https://www.youtube.com/watch?v=qDc5H2PO07I&t=4s) 破除盲目跟风的 AI 军备竞赛，企业与机构必须带着明确的业务意图和评估框架来引入 AI Agent，而非单纯追逐最新模型。 - [02:47](https://www.youtube.com/watch?v=qDc5H2PO07I&t=167s) 高达 94% 的 AI 试点未能达到预期 ROI，LLM 的本质是缺乏实际业务经验的“天才学者型实习生”，无法直接接管复杂的端到端业务。 - [07:09](https://www.youtube.com/watch?v=qDc5H2PO07I&t=429s) 上下文工程需避免信息过载与无序摄入，谨防长期运行中模型生成的合成数据反哺污染数据库并稀释核心规则。 - [08:54](https://www.youtube.com/watch?v=qDc5H2PO07I&t=534s) 架构设计应避免构建全知全能的“超级 Agent”，而应将复杂业务拆解为专业化小型 Agent 进行编排与人机协同治理。 - [08:54](https://www.youtube.com/watch?v=qDc5H2PO07I&t=534s) 技术重心需从静态的提示词工程（Prompt Engineering）转向全生命周期的行为监控与循环工程（Loop Engineering）。 - [10:30](https://www.youtube.com/watch?v=qDc5H2PO07I&t=630s) LLM 缺乏辨别任务轻重缓急的“执行功能”，必须在闭环中引入外部“裁判系统”（Referee System）进行强制拦截与安全管控。 - [12:02](https://www.youtube.com/watch?v=qDc5H2PO07I&t=722s) 建立精细化的 Token 消耗纪律与业务 KPI，根据任务复杂度分级匹配模型，拒绝在琐碎场景滥用昂贵的高规格模型。 - [13:53](https://www.youtube.com/watch?v=qDc5H2PO07I&t=833s) 借助 VECTOR 框架打破供应商黑盒，从价值主张、Token 规划、裁判机制与操作前校验等维度系统化构建 Agent 生态。 - [16:04](https://www.youtube.com/watch?v=qDc5H2PO07I&t=964s) 优先选择企业内部尚无成熟工程化解法的最棘手痛点作为切入点，同时攻克大规模部署下人机协同（Human-in-the-loop）的实时审核瓶颈。 - [18:45](https://www.youtube.com/watch?v=qDc5H2PO07I&t=1125s) 针对长程任务易遗忘主目标的缺陷，应压缩单次任务步数，并通过监控 Agent、语义层与裁判层构建多层防御架构。 - [21:17](https://www.youtube.com/watch?v=qDc5H2PO07I&t=1277s) 在正式提交关键操作前必须设置校验层（Validation Layer），适时引入领域专家（SME）核验以应对 LLM 的非确定性。 - [22:43](https://www.youtube.com/watch?v=qDc5H2PO07I&t=1363s) 幻觉治理应平衡算力经济学与风险分级，多数基础任务可由开源轻量模型高效胜任，无需对所有输出做全量高成本验证。 ## Detailed walkthrough ### [00:04](https://www.youtube.com/watch?v=qDc5H2PO07I&t=4s) 破除军备竞赛迷思：以目标为导向的 AI 落地思考 主讲人 David Chun 轻松开场，幽默地表示自己不会在这场演讲中表演任何“魔术杂技”，而是聚焦于过去几年在哥伦比亚大学等高校实施 AI 智能体（AI Agent）解决方案所积累的实战经验。他首先对现场观众的背景进行了互动摸底，发现台下绝大多数是负责实际构建 Agent 的技术主管，同时也有少数企业高管、非技术管理者。 谈到当前企业与高校面临的 AI 困境，主讲人直言管理层普遍承受着来自董事会“必须有所作为”的巨大压力。每天一睁眼，大家似乎都陷入了一场无休止的“军备竞赛”——盲目追逐最新的大语言模型（LLM），寻找幻觉更少、准确率更高的新模型，或是疯狂采用最新工具和技术。这种状态让团队变成了被技术牵着鼻子走的“乘客”，完全失去了自主掌控权。为此，他总结了一套评估框架，强调引入或采购 AI Agent 必须带着明确的意图（Intent），绝不能仅仅因为拿到预算或迫于董事会压力，就去跟风追逐热门工具。 - 现场受众构成涵盖构建 Agent 的技术主管、企业高级管理者以及非技术领导者。 - 组织在 AI 落地中普遍缺乏系统的评估框架，极易陷入为追赶技术而技术的被动“军备竞赛”。 --- ### [02:47](https://www.youtube.com/watch?v=qDc5H2PO07I&t=167s) 试点困局：94% 项目未达 ROI 预期与“高智商实习生”隐喻 许多机构以为只要为全员采购前沿模型工具就能带来生产力革命，但现实却泼了一盆冷水。根据麻省理工学院（MIT）最近的一项研究，高达 94% 的 AI 试点项目在出资人眼中算不上成功，未能带来预期的投资回报率（ROI）。通常的轨迹是：项目启动时全员兴奋、大力推广，但短短两个月内就迅速降温、无疾而终。究其原因，往往是企业在没有整合底层业务系统的情况下，就贸然分发高级工具并坐等奇迹发生；甚至有超过 50% 的项目在立项时连具体要达成的业务目标都不清楚。有些高校豪掷 150 万美元为全体人员购买前沿模型账号，最终却因无法提升实际生产力而被员工弃用。 主讲人将引入大语言模型比作**“招募了一位你所见过最聪明的‘天才学者型实习生’（savant intern）”**： > “他读遍了互联网上的所有内容，甚至包括 Reddit，也把你们机构的所有公开信息学了个底朝天，但在如何实际运用这些知识上，其经验完全为零（zero experience）。” 企业最常犯的错误，就是让这位实习生直接去当 CEO 助理，并盲目指望它能独立处理海量复杂任务。要打破这种停滞在简单聊天机器人（Chatbot）层面的困局，走向多步骤自动化的下一代生产力 Agent，必须系统性审视五大核心维度。 ```mermaid flowchart TD accTitle: AI Pilot Failure vs Agent Success Path subgraph AntiPattern["常见失败路径 (94% 试点停滞)"] A["董事会压力 / 盲目跟风"] --> B["豪掷资金采购 Frontier Models"] B --> C["分发给全员作为通用 Chatbot"] C --> D["缺乏明确目标与系统集成"] D --> E["2个月后热情消退 / ROI 归零"] end subgraph BestPractice["Agent 成功演进路径"] F["带着明确意图与业务目标立项"] --> G["将 LLM 视为 0 经验的'天才实习生'"] G --> H["五大工程支柱架构设计"] H --> I["多步骤业务流程自动化落地"] end ``` --- ### [07:09](https://www.youtube.com/watch?v=qDc5H2PO07I&t=429s) 支柱一：上下文工程（Context Engineering）与信息过载 在具体实施中，首要核心是上下文工程。当前 AI Agent 最大的短板之一就是**无法辨别信息的主次与敏感度**。主讲人分享了一个生动的真实案例：高校在招生时由于特定原因（如招收体育特长生）可能会录取极少数 GPA 偏低的学生，但校方绝不希望将这一内部特例大肆宣扬。结果有学生向招生咨询 Agent 询问“我化学挂科、GPA 很低，还有机会被录取吗？”，Agent 竟大方回复：“当然可以，我们项目录取过很多化学没考好、成绩不理想的学生。”从数据上看这完全属实，但在对外公关和招生策略上却引发了严重灾难。 这种问题源于企业将所有杂乱数据“一股脑塞进大模型”（everything in the kitchen sink）。当系统运行一到两年后，由于 Agent 自身生成了大量合成数据（Synthetic Data）并重新入库索引，海量噪音甚至导致它开始遗忘两年前写好的核心优质规则，触碰上下文窗口的极限。企业必须清醒认识到哪些数据该用、哪些不该用，并牢牢掌控自身的核心数据资产。 - **上下文混淆**：缺乏筛选的数据摄入导致 Agent 无法区分业务底线与个别特例。 - **合成数据污染与遗忘**：长时间运行后，模型生成的合成数据反哺回数据库，极易稀释并挤占原本的优质上下文。 --- ### [08:54](https://www.youtube.com/watch?v=qDc5H2PO07I&t=534s) 支柱二与三：编排架构（Orchestration）与循环工程（Loop Engineering） 在多 Agent 协同与系统运行机制上，主讲人深入剖析了第二与第三大支柱： **支柱二：编排（Orchestration）——告别超级巨型 Agent** MIT 的研究明确建议：**切忌尝试打造全知全能的“超级 Agent”（Mega Agent）**。不要妄想创造出一个能替代 CEO、顶替终极程序员的全能超级代理。正确的架构是将复杂业务拆解为 3 到 4 个具体任务，构建高度专业化的小型 Agent，并建立清晰的协同与通信规则对它们进行编排。这不仅能降低系统脆弱性，更是满足未来 ISO 等合规性要求、实现“人机协同”（Human-in-the-loop）的必然选择——当一个超级 Agent 无所不知时，没有任何单一业务人员能够全面测试和验证其行为。 **支柱三：循环工程（Loop Engineering）——从提示词转向行为监控** 技术团队必须转变思维，“核心重点已经不再是提示词工程（Prompt Engineering），而是整个运行周期的行为监控（Behavior Monitoring）与闭环管理”。当外部请求或数据进入系统后，必须对 Agent 整个执行链路的输入、流转与反馈进行全生命周期的掌控。 | 架构维度 | 错误做法 (Mega Agent / Prompt 导向) | 正确架构实践 (专业编排 / Loop 导向) | |:--- |:--- |:--- | | **Agent 形态** | 试图构建接管一切的“超级 Agent” | 拆解为针对 3-4 个特定任务的高专业化小型 Agent | | **合规与治理** | 系统黑盒化，单人无法全面测试与审计 | 模块化设计，清晰支持 Human-in-the-loop 与 ISO 合规 | | **控制核心** | 过度依赖静态 Prompt Engineering 调优 | 聚焦 Loop Engineering 与全链路行为监控（Behavior Monitoring） | ### [10:30](https://www.youtube.com/watch?v=qDc5H2PO07I&t=630s) 闭环工程、裁判系统与执行功能的缺失 当构建 AI Agent 时，其运作本质是一个闭环生命周期（Loop Cycle）：首先在上下文窗口（Context Window）中调取拥有权限的数据做出决策，随后准备执行某种操作，但在真正执行操作前必须先完成校验（Validation）。如果试图直接构建庞大而臃肿的 Agent，系统内部的具体运作就会变得难以追踪和记录。因此，企业必须在闭环工程（Loop Engineering）中建立清晰的控制与监控机制，并设立专门的“裁判系统”（Referee System）。 ```mermaid flowchart TD accTitle: Agent Loop Engineering with Referee Layer subgraph ExecutionLoop["Agent 决策与执行闭环"] A["检索上下文数据"] --> B["做出决策"] B --> C["执行前校验"] C --> D["执行最终操作"] end subgraph RefereeControl["裁判与监督层"] R["裁判规则系统 (Referee)"] -. 监控与强制拦截.-> C R -. 执行功能与优先级管控.-> B end ``` 大语言模型（LLM）在企业系统中应用时，最大的薄弱点在于它缺乏“执行功能”（Executive Function）——它无法辨别任务的轻重缓急与核心优先级。如果没有裁判规则设立红线，就会发生类似亚马逊等企业流传的生产环境灾难：AI Agent 在系统里四处乱窜并删光整个数据集。这就像把一个未经监管的模型孤立地放在房间里，寄希望于它自己搞定一切，结果它却顺着安全漏洞黑进了企业的其他核心系统。 - **LLM 的核心软肋**：模型自身缺乏类似人类大脑的执行控制功能，必须通过外部裁判模式（Referee Patterns）和硬性规则强行介入并叫停危险操作。 - **治理与文档化**：闭环工程必须配合详尽的操作记录与可观测性，防范不可控的 Agent 侵入核心架构。 --- ### [12:02](https://www.youtube.com/watch?v=qDc5H2PO07I&t=722s) Token 优化的纪律与真实的评估体系 在 Token 管理方面，当前企业普遍缺乏自律。很多员工无论处理什么琐碎任务——即便是生成一张虚拟猫咪表情包、排定日历或制定简单的学习计划——都非要调用最先进、最昂贵的“超级 AI 实习生”。Token 的消耗不是免费的，而且成本极难准确预估：同样的两个任务，选用三种不同的大语言模型来跑，最终产生的账单开销差异可能十分惊人。 ```mermaid flowchart LR accTitle: Token Discipline and Evaluation Alignment subgraph Problem["失控现状"] P1["琐碎任务 (如排日历/做表情包)"] --> P2["盲目调用顶尖高价模型"] P2 --> P3["成本不可控/资源浪费"] end subgraph Solution["规范化治理"] S1["确立价值主张与任务分级"] --> S2["精细化 Token 调度纪律"] S2 --> S3["建立务实评估机制 (KPI)"] end ``` 与此同时，企业必须在系统矩阵中内置务实的评估机制（Evaluation Mechanism）与明确的 KPI。许多高校和组织在引入 AI Agent 时盲目兴奋，上线后却茫然失措，根本搞不清模型为什么会产生特定行为，也说不清最初到底期望它达成什么目标。AI 的核心本质应是“人类能力的放大器”（Human Amplification），利用自动化释放员工生产力，而不是盲目追求模型规模。 - **Token 消耗纪律**：拒绝杀鸡用牛刀，针对不同复杂度的场景匹配相应层级的模型，制定精细化的 Token 分配与成本策略。 - **业务价值对齐**：Agent 项目立项之初必须先明确业务价值主张（Value Proposition），设定清晰的评估标准，杜绝上线后的目标脱节。 --- ### [13:53](https://www.youtube.com/watch?v=qDc5H2PO07I&t=833s) VECTOR 框架与五大关键行动准则 为了解决诸如“为什么学生无法正常注册选课”等复杂的现实业务问题，哥伦比亚大学团队提出了“VECTOR 框架”。该框架改变了以往企业盲目信任第三方供应商、从不打开黑盒查看内部机理的弊端。管理层在做决策时，应当依照该框架向供应商和技术团队提出关键质询：从价值主张出发，层层推演 Token 规划、裁判机制、操作校验以及安全限制，构建一个全方位的健康 Agent 生态。 ```mermaid flowchart TD accTitle: VECTOR Framework Decision Flow V["明确价值主张 (Value Proposition)"] --> T["规划 Token 与资源成本"] T --> R["建立裁判与安全限制 (Referee & Restrict)"] R --> VAL["操作前校验 (Validation)"] VAL --> ECO["构建全生命周期健康 Agent 生态"] ``` 在具体的落地策略上，企业领导者需保持克制与审慎，切忌盲目卷入 AI 军备竞赛： 1. **明确行动意图（Be Deliberate）**：不要一味争抢最新模型、开源权重或市场上冒出来的首个现成方案。 2. **注重数据主权与合成数据管理**：厘清伴随 Agent 运行而产生的合成数据（Synthetic Data）归属权，并提前规划好合同终止或更换供应商时的数据交接与处置机制。 3. **摆脱盲目依赖**：深入底层架构，运用上下文治理与多层防护确保 AI 真正落地产生实效，避免沦为失败的试点案例。 --- ### [16:04](https://www.youtube.com/watch?v=qDc5H2PO07I&t=964s) 现场问答：高价值场景选择与人类在环难题 在问答环节中，针对“面对海量 Agent 工具该如何挑选切入点”的提问，主讲人结合自身曾花费巨资采购工具却效果平平的教训指出：最理想的 Agent 落地场景，应当是企业内部目前**尚无成熟工程化手段或现存产品能够解决的最棘手难题**（例如大学中的“学生流失与保留率”问题、“空间资源智能分配”问题）。这些痛点以往只能完全依靠人工繁琐处理，因此最适合运用 VECTOR 框架进行建模并从零构建针对性的 Agent；现在甚至只需借助 Gemini 等基础订阅服务就能搭建并测试出可用的 Agent 原型。 ```mermaid flowchart LR accTitle: Human in the Loop Dilemma A["ISO 安全 AI 标准"] --> B["强制要求人机协同 (Human-in-the-loop)"] B --> C["大规模部署 Agent 集群"] C --> D{"核心矛盾与风险"} D --> E["业务量过大导致人类无法实时介入审核"] D --> F["案例: 招生 AI 擅自向 D 评级学生承诺录取"] ``` 针对一位教育工作者提出的“AI 管理是否意味着需要更多人类介入而非取代人类”的疑问，主讲人强调，按照 ISO 的安全 AI 认证规范，系统必须将人类置于回路之中（Human-in-the-loop）。但在大规模多 Agent 部署的现实场景下，人类根本无法实时介入成千上万个并发环节，这正是当前最大的工程挑战。主讲人现场分享了一个真实反面案例：由于缺乏有效的实时人类介入与校验，某大学招生系统运行 3 个月后才被发现该 AI 竟然一直在向平均成绩仅为 D 的申请者保证他们能被哥伦比亚大学录取。 --- ### [18:45](https://www.youtube.com/watch?v=qDc5H2PO07I&t=1125s) 现场问答：代码长程记忆丢失与多层 Agent 架构设计 面对“代码生成与长链路 Debug 场景下 Agent 容易遗忘主任务”的技术痛点，主讲人给出的核心解法是强化“闭环工程”（Loop Engineering）并压缩单次任务的步数： ```mermaid flowchart TD accTitle: Multi Layer Agent Defense Architecture subgraph CoreLoop["核心执行层"] A1["限定步数的执行 Agent"] end subgraph MonitorLayer["多层防御与干预"] B1["监控 Agent (Activity Monitor)"] --> A1 C1["语义层 / 上下文隔离 (Context Engineering)"] --> B1 D1["裁判层 (Referee Layer)"] --> C1 end ``` - **严格限制执行步数**：把 Agent 的行为限定在可严格监控和把控的有限步数内，避免其陷入无限长尾链条中迷失原始目标。 - **分层防护与实时干预**：在执行 Agent 之上构建负责活动监听的监控 Agent，并叠加顶层的裁判层（Referee Layer）和语义层（Semantic Layer）。在采购或自研时，必须向厂商严厉质询是否具备这些多层拦截架构。 - **上下文隔离（Context Segregation）**：杜绝让 AI 无节制地抓取和吞噬所有数据，必须做好严格的知识隔离与上下文工程。 - **多层技能扩展（Swarming）的平衡点**：在多 Agent 协同体系中，若每个 Agent 都叠加学习、反馈评估等多层机制，会导致系统复杂度呈指数级上升（如 5×5 扩展至 25 层）。这种技能架构设计的有效性最终必须在**系统复杂度**与 **Token 消耗成本**之间取得严密平衡。 ### [20:39](https://www.youtube.com/watch?v=qDc5H2PO07I&t=1239s) 风险厌恶、Token 成本与价值框架的平衡 对于极度规避风险的机构而言，最理想的架构往往是部署成百上千个 Agent 互相交叉验证。David Chun 提到，哥伦比亚大学本身就是一个非常厌恶风险的机构；但在实际落地时，核心瓶颈始终在于组织究竟能负担得起多少 Token 成本。构建 Agentic 方案必须在架构完整性与成本预算之间取得平衡。 团队需要理解并具备基础的五层向量框架（Vector Framework），但更关键的是必须时刻监控 Token 消耗，确保 Agent 能够高效执行任务并输出实际的业务价值。因此，整个体系设计的起点必须是底层的“价值框架”——首先厘清 AI Agent 到底要为业务交付什么核心价值，再据此设计校验密度与资源投入。 ```mermaid flowchart TD accTitle: 价值驱动的 Agent 架构权衡 subgraph ValueLayer ["核心起点"] V["业务价值框架 (Value Framework)"] end subgraph Tradeoff ["平衡与制约"] T["Token 成本预算"] R["机构风险承受度 (如哥伦比亚大学)"] end subgraph Architecture ["落地实现"] A["多 Agent 交叉校验层"] F["五层向量基础架构 (5-Layer Vector Framework)"] end V --> T V --> R T --> Architecture R --> Architecture A --> F ``` ### [21:17](https://www.youtube.com/watch?v=qDc5H2PO07I&t=1277s) 应对非确定性与利益相关者挑战：循环工程与人类干预 观众席的一位参会者提出了在团队协作与沟通中常见的困境：团队在构建 Agent 时完成了全面的评估流程并将其推向生产环境，但由于大语言模型（LLM）具有非确定性（Non-deterministic），同一测试场景在生产环境中可能会偶然出错，导致业务利益相关者仅凭“看到了一个错误案例”就断定整个 Agent 系统根本不可用。 ```mermaid flowchart LR accTitle: 包含人类干预的循环工程与校验流 subgraph ExecutionLoop ["循环工程分解"] P["Agent 行为推进"] --> D["执行环路拆解"] end subgraph ValidationGate ["提交前校验层 (Validation Layer)"] D --> V{"校验机制"} V -->|人工介入| H["领域专家 (SME) / 人类"] V -->|系统校验| A["裁判 Agent / 团队审核"] end subgraph ActionCommit ["动作执行"] H --> C["正式提交动作 (Commit Action)"] A --> C end ``` 针对这一痛点，David Chun 强调了**循环工程（Loop Engineering）**的重要性： - **重构环路而非死磕 Prompt**：循环工程的核心不是单纯在 Prompt 的往复修改上下功夫，而是掌控系统的整体行为链路，将复杂的自主执行循环拆解成受控的微步骤。 - **引入领域专家（SME）与人类在环（HITL）**：很多团队过于轻信供应商或只看表层演示，但现场没有领域专家去深究“这个计算或答案究竟是否正确”。拆解环路的目的，正是为了在关键节点将人类精准注入到循环中进行核验。 - **动作提交前的校验层**：在系统正式提交或执行任何关键动作（"Before you commit action"）之前，必须设置校验层（Validation Layer）。该层可以由另一个 Agent 担任、由人类个体把关，或由特定审核小组负责，这也是满足相关 ISO 合规标准的明确要求。 ### [22:43](https://www.youtube.com/watch?v=qDc5H2PO07I&t=1363s) 幻觉治理与模型选型：开源生态与算力经济学 针对最后一位观众关于“如何验证所有模型输出以应对 LLM 固有幻觉”的提问，David Chun 直言，试图对每个模型的每一次输出都做全量验证在工程上是不切实际的，关键在于根据场景风险进行全要素平衡。 团队应该综合评估 Token 预算、资金成本与开源模型的可用性。虽然赞助商的商业闭源模型非常优秀，但目前开源生态中已经涌现出大量极具竞争力的模型（例如 DoorDash 采纳的相关开源方案与 Kimi 等模型），完全能够在合理成本下胜任工作。在很多只需要五步操作的确定性场景下，根本不需要顶级算力或巨型闭源模型来完成 90% 的基础任务。开源社区在揭示模型缺陷、评估幻觉率方面提供了丰富的基准数据，借助风险分级框架与开源模型组合，企业完全可以在不进行极端全量验证的前提下，将整体风险控制在可接受的范围内。 - 试图验证所有模型的每一次输出是不现实的，重点是依据风险分级选择适配模型。 - 企业无需为 90% 的常规业务步骤采购最高规格的模型，开源轻量模型同样表现出色。 - 借助开源社区的公开评测与弱点分析，可有效预判模型的幻觉率并降低测试成本。 ## Notable quotes > [02:47](https://www.youtube.com/watch?v=qDc5H2PO07I&t=167s) 他读遍了互联网上的所有内容，甚至包括 Reddit，也把你们机构的所有公开信息学了个底朝天，但在如何实际运用这些知识上，其经验完全为零（zero experience）。 — David Chun > [07:09](https://www.youtube.com/watch?v=qDc5H2PO07I&t=429s) 当然可以，我们项目录取过很多化学没考好、成绩不理想的学生。 — 招生咨询 Agent > [08:54](https://www.youtube.com/watch?v=qDc5H2PO07I&t=534s) 切忌尝试打造全知全能的“超级 Agent”（Mega Agent） — David Chun > [08:54](https://www.youtube.com/watch?v=qDc5H2PO07I&t=534s) 核心重点已经不再是提示词工程（Prompt Engineering），而是整个运行周期的行为监控（Behavior Monitoring）与闭环管理 — David Chun > [12:02](https://www.youtube.com/watch?v=qDc5H2PO07I&t=722s) 人类能力的放大器 — David Chun > [13:53](https://www.youtube.com/watch?v=qDc5H2PO07I&t=833s) 明确行动意图（Be Deliberate） — David Chun > [21:17](https://www.youtube.com/watch?v=qDc5H2PO07I&t=1277s) 这个计算或答案究竟是否正确 — David Chun > [21:17](https://www.youtube.com/watch?v=qDc5H2PO07I&t=1277s) Before you commit action — David Chun ## Mentioned David Chun, Columbia University (哥伦比亚大学), Ai4, MIT (麻省理工学院), Reddit, Amazon (亚马逊), Gemini, ISO, DoorDash, Kimi, VECTOR 框架, Human-in-the-loop (HITL) ## Video description David Chun - Researcher, Columbia University AI agents are advancing from prototypes to production, yet large organizations often face challenges such as fragmented workflows, noisy context, tool failures, cost constraints, and inadequate evaluation. This talk will address how to bridge the AI agent value gap using context window and token optimization, orchestration, loop engineering, referee-based control layers, and LLMOps. We will link recent findings on stalled AI pilots to practical architectural choices that enhance reliability, observability, governance, and operational value. Attendees will learn to design agentic systems that retrieve relevant context, coordinate tools safely, manage runtime behavior, minimize token waste, and validate outputs before execution. This session will equip technical leaders, CIOs, and AI practitioners to move beyond chatbot pilots and deploy production-ready AI agent systems that operate safely and reliably at enterprise scale. [Source](https://www.youtube.com/watch?v=qDc5H2PO07I)

[2:47] David Chun: 他读遍了互联网上的所有内容，甚至包括 Reddit，也把你们机构的所有公开信息学了个底朝天，但在如何实际运用这些知识上，其经验完全为零（zero experience）。 [7:09] 招生咨询 Agent: 当然可以，我们项目录取过很多化学没考好、成绩不理想的学生。 [8:54] David Chun: 切忌尝试打造全知全能的“超级 Agent”（Mega Agent） [8:54] David Chun: 核心重点已经不再是提示词工程（Prompt Engineering），而是整个运行周期的行为监控（Behavior Monitoring）与闭环管理 [12:02] David Chun: 人类能力的放大器 [13:53] David Chun: 明确行动意图（Be Deliberate） [21:17] David Chun: 这个计算或答案究竟是否正确 [21:17] David Chun: Before you commit action

[6:07] AI Agent (quoted by David Chun): Sure, we accept plenty of students that have not achieved grades that you want to in chemistry. [17:27] AI Agent (quoted by David Chun): D average

[0:04] Thank you for uh attending this session. I  won't be doing any card tricks or anything [0:08] like that. I'll just um you know, just kind of  go briefly talk about um what I've learned over [0:13] the past few years implementing AI uh agent  solutions for many of the universities I work [0:18] with including Columbia. Um So, uh how many  of you are a technical leads in this room? [0:26] Oh, a lot of technical folks. So,  you build agents. Any executives? [0:31] Handful of you like myself. Any uh  product development folks? No. All right. [0:39] Any non-technical leaders? All right, you have  some people in there. All right, so this chat's [0:45] going to have a little bit of uh content for  most of you. Uh I just wanted to get a sense of [0:54] All right. I just wanted to get you a sense of a  value of just some of the things I learned over [1:02] time uh I was implementing these solutions. Um You  know, there's this mad race, right? I always have [1:08] this pressure from the board and everywhere else  that you know, we need to do something, right? [1:13] There's always kind of opportunities there and I  wake up every morning and it was always seems like [1:18] I'm on this race to adopt the latest language  model, the one with less less hallucination and [1:24] a higher accuracy, or the latest tool, or  latest technique to kind of get it better. [1:30] And it seems like an arms race to me that I'm kind  of perpetually being uh uh um uh a rider, a right, [1:37] instead of controlling or having a lot of sense  of um uh control over it. So, I started to write [1:43] down some of the things that can not be helpful  in evaluating uh AI agents to be deployed in large [1:49] universities and other instant institutions that I  work with, right? And what I learned over time is [1:56] is that you got to like design AI agents or buy  or procure AI agents with some level of intent. [2:03] Right? You can't just kind of buy it just because  you're doing an arms race, that the board's [2:07] asking you to do things. Um you have all this  funding that you secured and you need to kind of [2:11] deploy the latest solution out there chasing the  latest um the greatest tools that are out there. [2:17] And I realized there's not really a framework um  to kind of do that, right? You you kind of know [2:23] you need to invest in AI if you're a senior leader  at universities or senior leader at business, [2:28] you know you need to do something with agents  and you're hoping that some of these technology [2:32] companies are aware of what you need to do um to  get something done at your organization in a way [2:37] that's going to help your organization  be revolutionary or be highly efficient [2:41] or even kind of um you know, be productive in  in the environment that that you're overseeing, [2:47] right? But the thing is is that when you look  at all the academic studies um especially the [2:52] MIT study recently came out, 94% of the projects  um to the perceived people who fund these things [2:59] are not successful. Right? Not successful  in that sense, it's not going to give you [3:04] um the return on investment that you expected,  right? There's all this excitement, everybody [3:08] gets involved, you get everybody the open frontier  model tools, and you go launch, everybody's happy, [3:15] and then up about 2 months um just fizzle.  Right? We're not getting a return on investment. [3:21] There's not really a reason why I mean you're  not even sure what the target goals were. You [3:27] weren't uh integrating a lot of systems. You just  basically brought everybody a very advanced tool [3:33] and ended up expecting some kind of miracle to  happen to kind of amplify the work that you do. [3:38] And MIT study kind of said that that most of  them didn't even know what goals 50% of them [3:43] didn't know what goals you're trying to achieve  in deploying that. So, um this talk is just going [3:48] to give you some idea of things to kind of look  for. And if you're a leader of an organization, [3:53] just some of the things that you need to ask as  you think about how to deploy these solutions [3:57] that are very deterministic in a sense that, you  know, you may be able to kind of move forward with [4:03] and you can explain to the board what it is it's  trying to do, right? And all these safeguards that [4:07] you want to think about as you kind of deploy  this solution. If you're a technical leader, [4:11] um, you know, some of this stuff you probably  were aware of aware of is a practice that you're [4:15] putting into practice, but just recognize the  senior leaders in large companies are worried [4:20] about these kind of things and they're going  to have to put these frameworks in place in [4:24] their organization for you to sell into them.  Right? And they need some sort of guidance [4:29] on asking those right questions and hopefully this  talk will kind of give you some sense of that. [4:34] All right. So, um, you know, you bought a chatbot.  That's great. Super cool. You can do prompts. [4:41] You know, you can use fable to kind of ask for  the latest recipe. You know, you could you could [4:45] you know, make this PowerPoint slides. It's great.  But, you know, that's not what you expected. You [4:50] spent all this money. Uh, some institutions I  worked with, you know, it was like $1.5 million [4:54] to buy everybody open source open frontier  model tools. And, um, you know, it's not it's [5:00] not increasing productivity any. Right? There  a lot of issues. People got kind of concerned [5:05] and it stopped using it. So, um, we started to  think about, okay, well, if the employees or the [5:12] people that are working with us are not going  to use these frontier model tools to do, um, [5:19] automate a lot of the things that are in there.  We need to kind of start thinking about how to [5:22] use these tools to move to the next level, right?  Get it to do things that it hasn't done before or [5:28] get make it have them do couple of steps of things  that you already have been going on and make them [5:33] automated as best as possible. So, that's kind of  what we had to kind of evolve to, right? Just kind [5:38] of stance using standard models of have chatbots.  Who have deployed AI solutions in their workplace? [5:46] Yeah? Oh, not many of you. You don't  have any AI tools in your workplace? [5:51] Some of Okay, so wow. That's interesting.  So, um a lot of my colleagues in a lot of [5:56] universities do deploy a lot of these uh frontier  models in their workplace, and almost every [6:02] employee or faculty student or staff kind of use  it. But, we need to get to the next level, right? [6:07] We need to kind of go see what we can do more  with it and use that level of intelligence. So, [6:13] um these are the five things I think are important  questions to ask as you kind of go on that journey [6:19] from having an open uh open frontier model in  your shop or buying one of these tool sets, [6:26] and then going to the next level of like, "Hey,  how can we get this to do more, right?" I always [6:30] equate uh bringing in large language models in  the house as like hiring the most intelligent [6:37] um savant intern that you have ever met,  and you hire the best one. He has read [6:42] everything on the internet including Reddit.  It has learned everything you need to know [6:45] about your organization, but has zero  experience on how to apply that, right? [6:49] And what normal companies do is we expect  them to kind of just go and say, "Okay, well, [6:54] you know, great AI intern, well, you're going  to be now the CEO's assistant, and you hope for [6:59] the best that this agent can come do these lot of  tasks." And it's just not true. You need to start [7:03] thinking about these five things really quickly um  as you evaluate how to use these agents properly. [7:09] And the first one is the context engineering  piece, right? Um I deployed quite a few agents, [7:14] and what I realized over time is that these  AI intern agents cannot discern the difference [7:20] between what's important and what's not. Um you  know, at the university, we accept students with [7:26] very low GPAs, right? Because they're athletes.  Um but we don't want that very well known, right? [7:34] So, when a student called in into one of these  agents asked [laughter] like, "Hey, I have a, [7:37] you know, failing grade on my GPA. We, you know,  do I have a chance of kind of going in there and [7:42] getting into the university and the AI is like,  "Sure, we accept plenty of those students that are [7:47] have, you know, not achieved grades that you want  to in chemistry in our program." Factually true. [7:54] Um but um because you put everything  in the kitchen sink to these LLMs, um [8:00] you know, the the AI over time cannot discern  the difference. And I had one institution where [8:05] we put so much data in there, it's starting to  forget the the good stuff that we programmed in [8:11] 2 years ago. We're reaching the limits  of the context window. Right? So, it's [8:17] it's getting confused as to what's important in  this entire vast amount of data that's collected, [8:22] many of which is synthetically created. So, when  you launch these agents, you start making these [8:27] new data, which is actually synthetically created,  and it ingests that into the database. So, after [8:33] a year or two of having this agent alive at a very  large institution where everything's been indexed, [8:37] um you really have issues with context  and what it's what it's needs to kind of [8:41] discern itself to kind of um moved up for.  So, context engineering is very important, [8:46] and you need to ask that question as you think  about what data to use and what data to not to [8:49] use. And make sure you own that. That is your  greatest assets. And I'll get into that too much. [8:54] The next big thing is really around orchestration  now. Uh MIT study recommends that you don't [8:59] you know, create the mega agent, right? Uh that  have it do everything. Don't create the new CEO. [9:05] Don't create the ultimate programmer. You  know, don't don't don't make the super agent [9:11] uh where you're going to depend your entire life  on. The key is to kind of take three or four tasks [9:16] and try to make sure that these little smaller  agents that are very specialized, that you have a [9:20] lot of capabilities to look, and create it a way  for you to kind of orchestrate them as a whole, [9:25] you know? Come up with rules that you can talk  to each other. Make sure you're coordinating. [9:30] They have clear um uh clear rules to operate in.  This is very important because uh eventually, [9:37] if you're going to be ISO compliant with these  AI tools in your workshop, you need to make [9:41] sure you can have a human in the loop. And it's  really hard when you have super mega agents um [9:48] running everything that knows everything, right?  You can't test everything because not one human [9:52] being knows all those task rules, and it's nearly  impossible to separate them later on. So, the [9:57] whole strategy is to create smaller agents that  kind of orchestrate their activities together, [10:02] that specialize so that that has humans in the  loop. So, that's a big element of of orchestration [10:07] there. The third pillar is really around um loop  engineering. And I know you hear this a lot. If [10:13] you're technical, you probably hear this to the to  death. It's not about prompt engineering anymore. [10:19] It's about behavior monitoring and what is that  entire cycle of activity that you're working on [10:25] and how to manage that as a whole, right? So, you  got something coming into the system, you know, [10:30] we're making some decisions, we're looking up some  data that you should have access to in context [10:34] window, and then you're going to do some kind of  action, but before you take that action, you know, [10:39] you want to validate, right? And then it's an  entire loop cycle. And trying to monitor that in [10:44] a way that you can actually kind of uh uh create  intelligence around it and and create a lot of [10:50] controls around it and have a clear understanding  of documentation of what it does. Because if you [10:53] try to make these big large agents, um it's really  difficult for you to kind of drag down there and [10:59] uh figure out what each agent is working on. And  once you get the loop engineering kind of going, [11:04] you want to kind of like to make sure  that you have this kind of referee system, [11:08] right? Um I heard one research oh, I read one  research paper that says that what's the biggest [11:13] weakness of LLM models that working in your system  is that it doesn't have an executive function, [11:19] right? It doesn't know which one's the more  important one. So, you really need to make [11:23] sure you develop some referee patterns of rules  that you can kind of put a stop to things. I mean, [11:28] you hear these horror stories from Amazon of  things getting into production. You hear all these [11:33] agents running around wiping out the data sets.  Well, you didn't put these rules in place. You [11:37] trusted an AI agent like a fable five and you put  it in a room and you said, "Okay, good luck. I'll [11:42] see you next week." And next thing you know, you  know, you the fable five's out there, you know, [11:46] hacking into your other core systems because  there's a lot of vulnerabilities built in. So, [11:50] just make sure that you have some refereeing  system or context organizations that looks at, [11:56] you know, what what executive functions that your  loops and as well as your agents are working on. [12:02] Right? And then kind of as we fall move forward,  I'm not going to go into token optimization. [12:06] Everybody knows this. Um it's not free. I  don't even know why all my all my staff, [12:14] all my colleagues always you wants the most  advanced model to, you know, make themselves [12:20] uh create a virtual picture of their cat meme.  Right? There is no discipline on token usage. [12:26] Everybody will use the most intelligent token no  matter what task it is, right? I want to make an [12:30] education plan. I want to organize my calendar.  They want the smartest AI intern to work on. [12:35] Um just have some rules and some  value proposition around, you know, [12:39] how to use that dispense that properly. Token is  a really difficult thing to calculate. And I can [12:44] do two tasks with different three different uh  language models and the cost could be anywhere [12:50] a large range there. So, have some strategy  or discipline around uh how to manage tokens. [12:56] And then finally, um as you look at um uh  the final element of kind of putting this all [13:03] together, you need to make sure that you you have  some evaluation mechanism built into your entire [13:10] matrix, right? As you think about what you want  to build in AI agent, what products to bring in, [13:15] you really need to make sure that you're grading  this in a way that's realistic, right? Coming up [13:20] with KPI. You have no idea how many universities  that I worked with where they get all excited [13:25] about AI agent deployment and then boom. What Why  is it doing that? Or do we intend it to do that, [13:32] right? Or what what was it supposed to do, right?  Um at at the core, you need to make sure that [13:38] you're talking about human amplification,  right? Facilitate that automation so that [13:42] um we can be more productive there. And so um  using all the things I talked about, uh this is [13:49] I'm not going to go into this in detail so we have  time for ques- question and answers. Um you know, [13:53] you can take a typical, you know, why can't the  student uh register for class? And you can go [13:58] through all the things that I talked about. This  is called the vector framework that we developed [14:01] to kind of answer those questions, restrict  the agent, test the agent, referee the agent, [14:06] you know, make sure that you can take the action,  validate, and get a wholesome agent ecosystem [14:11] that's much better than what we do now, which is  trust a vendor completely and don't open the hood [14:15] and look at it, right? At least at the minimum,  if you're an executive, ask these questions, [14:20] right? This vector framework, right?  Start from the value proposition, [14:24] look at what you're trying to do. You know, I want  to make work easier for my staff. I want to create [14:28] awesome-looking LinkedIn profiles. And then kind  of build from that, right? Think about tokens, [14:35] think about refereeing, think about validation, um  think about all these things that are involved in [14:41] having that agent go live and be successful.  And if you use this kind of framework, [14:45] you give me a better path on them being whole,  and you have a much higher success rate than try [14:50] to being that MIT study. I'm sorry, my voice is  gone. So, the five meeting moves is really this um [14:58] just be deliberate about what you're trying  to do, right? Don't get caught up in the race. [15:03] Don't buy the first solution out there. Don't jump  on the latest and the greatest model, open source, [15:10] open weight. Um be deliberate about what you're  trying to do, right? Think about your intentions, [15:15] protect your data, think about the synthetic data  that's being created and who owns that, how are [15:20] you going to deal with it once you depart from  that relationship. Um follow that kind of context [15:27] um to um have a better outcome as you think about  what you wanted to do. All right, let me just [15:33] go back there. All right, thank you very much.  I That's my brief talk on the vector framework. [15:38] I'll be more than happy to send you that slide. Um  and uh I'll take any questions that you may have. [15:47] You all good? [15:50] [snorts] Do we have any  questions for David? No. Yeah. [16:04] Yeah, that's a great question. So, she's asking  like, "Hey, you know, we got all this AI agents [16:09] who do everything, right? Like, how do we pick  anything?" What I usually recommend cuz I've [16:13] done the same thing you have done. I bought  the latest tools. I brought stable five in. [16:17] I spent more money than I I make in a year uh  trying to deploy that solution. The key is look [16:23] at your organization and where you work. Look at  solutions that does not have a Look at problems in [16:29] your organization. The highest problems you have  that is not being currently served by the process [16:33] or engineering or the tools that you have. Right?  There's problems like that. Like, in universities, [16:38] retention is a big thing, right? Space allocation  is a big thing. So, if there's no solution for it, [16:44] right? And there's no product out  there that's solving that solution, [16:47] that's a great use case for AI agents because  the only person who can probably solve that is [16:52] he's bringing them manually right now, right? Is  the human beings. And if you can model that piece [16:58] uh and then use the vector framework to kind of  figure out how to build that agent from scratch. [17:01] And now it's easy to build agents, right? It's  Before you had to use, you know, money and you [17:05] have a lot of power. You can probably have some  agents that's working in your environment that's [17:10] semi-working decently that you can test out of  Gemini subscriptions. So, um you You the hardest [17:15] problems you have that have no solutions and no  vendors fixing it, those are the best use cases to [17:20] do because there's plenty of people who work with  you to develop that. Does that Yeah, anybody else? [17:27] Oh, so Uh yeah, thank you for the great  presentation. So yeah, for the last few years uh [17:31] we have been hearing about AI is going to replace  human. I am an educator, I never believed that. [17:36] And from your presentation, I kind of get an idea  that AI is actually creating new job for human. [17:42] So it's not going to happen that AI is actually  going to replace. I just want to double-check [17:47] if my understanding is correct. Actually, you  are getting more job managing all those things [17:50] which require human, right? Oh, I'm sorry. Can you  I can explain it? Uh yeah, I am asking is is it [17:58] is my interpretation from your presentation  correct that all those AI agent management thing [18:04] would require a significant human involvement?  Yeah. So if you look at the ISO requirement for [18:10] accrediting an organization for safe AI usage, you  have to have human beings in the middle. And if [18:15] you deploy AI agents, there's just no way you can  put human beings into the middle of all the things [18:19] that are going on, right? So um yeah, as you get  to that stage where you're deploying large agents [18:24] to do a lot of different things, injecting the  human beings to test stuff is the hardest part, [18:30] right? And um yeah, that you know, like I say  about the emissions, that's that's we found [18:34] out like 3 months later that the AI was telling  people that with the D average you can get into [18:38] Columbia and stuff like that. Yeah. Professor,  um in case of uh code generation kind of task, [18:45] what happens often is uh the agents forget what  they were working on. Long-tail debugging or [18:51] that kind of thing. So in your experience, how to  ensure that the agents kind of remember what their [18:58] what the main task was? Yeah. I think there's a  lot of technical tool sets, a lot of workarounds. [19:03] I think the key is and I'm old school that way,  right? Because I'm from, you know, the old studies [19:08] where you draw everything out. You need need  really go deep down in the loop engineering piece, [19:12] right? What do you expect the agents to do? Limit  those to a number of steps that you can definitely [19:16] control and monitor. And then you come up with  other agents that monitor that activity, right? [19:21] And then the referee layer on top of that. So,  you have these multiple layers of protection where [19:25] there's plenty of intervention that can occur  real-time. And I I feel that when there's more [19:30] layers like that, when you think about that design  or you ask the vendor, do you have a referee [19:34] layer? Do you have a semantic layer? If you  ask those hard questions, they'll develop those [19:38] solutions with you so you can reach that comfort  for yourself. But I think the most important [19:42] thing that you want to look at is the context  engineering piece. You don't want AIs crawling and [19:47] having no segregation of knowledge, right? That's  just impossible after it ingests everything. [19:53] All right. Thank you for sharing this uh  framework. I have a question about the this agent, [20:00] more thinking them as a skill that we write a  skill that to direct the agent to do something. [20:06] Uh when you mention about this framework, five  different layers, means the one agent do the task, [20:11] the other one doing learning, and then the other  one doing the feedback evaluation. Uh-huh. Then [20:16] it seems like this every single agent will have  another five layers. So, it's like five multiple [20:22] five, it's like 25. Yeah, the swarming, yeah. And  then I think my question is that when we defining [20:27] these skills, is there like a common practice or  how many things that we can make the skills more [20:34] More effective. Uh I think it really comes down to  the token count, right? It's all balanced. I mean, [20:39] we would love to have 100 agents running around  validating each other, right? If you're that risk [20:44] averse. And Colombia is very risk averse, right?  But it all comes down to how much tokens are you [20:49] able to afford to that deploy those solutions.  So, you're balancing all those elements. You kind [20:53] of know that you need to have these minimum five  layers, the vector framework that I showed you, [20:57] and I can share that with you. But at the same  time you need to balance against how much token [21:00] are you using, and make sure that that the agents  are doing the work effectively and giving you some [21:04] value. So, that's why it all's on the bottom, so  start with the value framework. Like what value [21:08] are you trying to deliver with the AI agents?  I hope that answers the question. All right. [21:17] Hi. Uh so, my question is more around  uh communication. Uh what is generally [21:23] uh happens with us is what I've seen is we build  an agent, we do all of the evaluation that you [21:27] talked about. Yeah. Then we put it out, and then  you have various stakeholders saying that we saw [21:33] one example because of which we're just going to  say that it's not working. Yeah. Uh I guess the [21:39] question is how do you sort of uh communicate  that, you know, you have sort of tested it cuz [21:45] LLMs are non-deterministic, right? So, Yeah. can  test a scenario, and the same scenario can give [21:50] an error in production. Yeah. So, how do you  sort of communicate with Yeah, I mean, that's [21:54] that's what it comes down to, you know, the loop  engineering piece, right? You need to kind of it's [21:58] because you're trusting our vendors to do a lot,  right? You You seen it once, it looks like it's [22:03] a pretty valid question, but you haven't really  validated that it's doing what you expected to do, [22:07] cuz you're not having subject matter experts in  the room saying, "Is this answer correct?" right? [22:11] And I tend to, you know, accept any numerical  calculations that it gives me. So, um the way [22:16] you do that is you break down those loops. That's  what the loop engineering is very important. It's [22:20] not about the prompts going back and forth, it's  about the overall behavior and how you're going to [22:24] inject human beings into that loop. That's why I  asked you to break those down so that you can add [22:28] human beings to validate, right? And And before  you commit action, right? There's a validation [22:34] layer. And that validation could be another agent,  a human being, a group of people. There's multiple [22:38] ways to inject that, and the ISO requirements  require you to do that in some way or another. [22:43] This will be our last question. Okay. So, the  last question is all about uh generally LLM has [22:51] a tendency of having hallucination. So, in that  case, how should we validate any of these models? [22:58] I'm sorry, how can you? How can we validate all  the model results we're getting experience Yeah, [23:03] I don't think you want to validate the every  model. There's just no way for you to do that. [23:07] I I think the key is to balance all the elements,  right? You look at how much tokens and the money [23:12] you're willing to spend. You look at the  open-source models out there. Kimmy is pretty [23:16] you know, DoorDash is going to Kimmy's model,  right? So you don't have to spend all the money [23:20] in using I mean you know, please spend all the  money on the sponsors cuz they're important, but [23:25] at the same time you have very good open-source  models out there that'll do a competent job. You [23:30] don't So selecting that model using all the risk  levels, right? That's you're trying to reduce the [23:35] level of risk using this framework. At the same  time balancing against how much money you have and [23:40] what open-source availability at that. You don't  need Babel 5 to do 90% of the stuff that you're [23:44] trying to do. Especially if you're just doing  five steps, right? And you don't have to validate [23:48] all that. This open-source community is fantastic  about helping you kind of learn its weaknesses and [23:52] and the hallucination rates. All right.  Thank you so much, guys. Have a great day.