一个工程师在波士顿追问：AI智能体落地还差什么

当演示视频里的智能体流畅完成复杂任务时，台下掌声雷动。但散场后，真正负责部署的工程师开始头疼：成本怎么控？出错了谁背锅？

这是QCon AI Boston 2026试图回答的问题。6月1日至2日，这场技术大会将在波士顿大学举行，议程刚刚公布。与多数AI活动不同，它不聊模型参数，只聊"演示之后"的工程深渊。

项目主席Eder Ignatowicz现任Red Hat AI高级首席软件工程师兼架构师。他设计议程的核心假设很直白：能让老板点头的Demo，和能在生产环境扛住流量、成本、审计的系统，中间隔着一整条产业链的空白。

LinkedIn的上下文工程实验

Ajay Prakash，LinkedIn高级主任软件工程师，将分享一个具体案例：如何用MCP（模型上下文协议）搭建组织级的上下文层。

MCP是Anthropic去年推出的开放协议，旨在标准化AI模型与外部数据源、工具的连接方式。Prakash的团队把它用在了更底层——不是让单个智能体调用工具，而是让整个公司的AI系统共享同一套上下文理解。

这个设计的痛点很真实。企业里的AI智能体往往各自为战：客服机器人读不懂订单系统的状态，代码助手看不到部署管道的限制。Prakash的解决方案是把"组织知识"抽成一层独立服务，让不同智能体在同一套事实基础上运作。

他会在现场拆解实现细节：协议选型、数据权限模型、版本冲突处理。这些正是Demo里永远不会出现的脏活。

成本与可审计性的双重绞杀

Inference（推理）成本是议程的第二条主线。大模型调用按token计费，生产环境的流量放大效应会让账单失控。一位演讲者将讨论缓存策略、模型路由、量化压缩的工程权衡——不是"用哪个模型更好"，而是"怎么让现有模型更便宜地运行"。

另一条暗线是审计。非确定性系统（nondeterministic systems）的决策过程难以复现，这在金融、医疗等强监管领域是致命缺陷。议程中有专门环节探讨如何让AI系统的行为可追溯、可解释、可回滚——不是做给合规部门看的文档，而是嵌入架构的工程能力。

AI在软件开发生命周期中的位置重构

第三条线索更激进：当AI深度参与编码、测试、部署，SDLC（软件开发生命周期）本身需要重新设计。

传统流程假设人类是决策主体，AI是辅助工具。但当AI生成的代码占比超过某个阈值，代码审查、版本控制、责任归属的逻辑全部失效。议程中有多个案例来自实际落地团队，讨论"人机协作"从修辞变成架构时的具体摩擦点。

Ignatowicz的选稿标准在这里体现得很明显：拒绝"AI将改变一切"的抽象预言，只要"我们试了，这里卡住了"的一线报告。

为什么是波士顿，为什么是现在

QCon系列由InfoQ主办，向来以工程深度著称。选择波士顿而非硅谷，选择6月而非年初的CES或年尾的NeurIPS，时间点本身就有意味。

2024-2025年的AI投资热潮催生了大量概念验证项目。到2026年中，这些项目要么进入生产环境，要么暴露致命缺陷。大会日程瞄准的正是这个窗口：第一批试错者已经摔过跤，教训还新鲜，但尚未被包装成"最佳实践"的陈词滥调。

参会者名单尚未公布，但从演讲者背景可推测受众画像：Red Hat、LinkedIn、以及议程暗示的其他企业工程团队——不是研究实验室，而是负责维护现有系统、承受业务压力的从业者。

一个尚未被回答的问题

议程覆盖了技术层面的三个硬骨头：部署、成本、审计。但有一个变量被刻意留白：组织变革。

让智能体进入生产环境，最终需要重新定义"谁对什么负责"。当AI系统的决策导致业务损失，是模型提供商、部署团队、还是使用部门担责？议程中的工程方案能解决技术可行性，但权责框架的模糊可能才是最大的落地阻力。

Ignatowicz在议程介绍中用了"gap"（鸿沟）这个词——不是技术差距，而是"impress stakeholders"与"hold up under production"之间的系统性落差。这个观察本身比任何具体方案都更值得注意：它暗示2026年的AI产业，核心矛盾已经从"能不能做"转向"谁敢用"。

大会最终能产出多少可复用的工程方案，取决于演讲者愿意暴露多少失败细节。从目前的议程设计看，组织者至少在试图建立一种诚实的对话氛围——这在当前AI舆论场中已属稀缺。