| 1 | # 01_cover |
| 2 | |
| 3 | 大家好,欢迎来到这次技术分享。今天的主题是 AI Agent 工程化与落地——也就是说,我们不聊新模型,不聊新论文,专门聊一件事:怎么把那些跑得动 Demo 的 Agent,真正搬进生产环境里。 |
| 4 | |
| 5 | --- |
| 6 | |
| 7 | # 02_hero_demo_to_prod |
| 8 | |
| 9 | 先抛一个让人有点不舒服的事实。在我和很多团队的交流里,大约九成的 Agent 项目最后都停在了 Demo 阶段。原因不是模型不够强,也不是想法不够好,而是要进生产,需要跨过四道工程化门槛——架构、上下文、评估、可观测。这四件事一件没做,Demo 就永远只能是 Demo。 |
| 10 | |
| 11 | --- |
| 12 | |
| 13 | # 03_three_pains |
| 14 | |
| 15 | 第一道是性能不稳定,多步推理一叠加,每一步五到十个百分点的抖动累计起来,整体成功率就会断崖式下滑,P95 延迟更是常常翻五到十倍。第二道是成本不可预测,同一个任务在不同上下文长度下,单次 token 消耗能漂移五到五十倍,长尾任务尤其会吞掉预算。第三道是质量难闭环,失败原因是模型问题、提示词问题、还是数据问题往往说不清楚,回归测试也没有,一改 prompt 就提心吊胆。这三道门槛,是绝大多数项目都会先撞上的。 |
| 16 | |
| 17 | --- |
| 18 | |
| 19 | # 04_agent_architecture |
| 20 | |
| 21 | 接下来我们看一下 Agent 的标准骨架。基本上可以分成四层。最上面是感知层,负责输入解析、多模态融合、上下文窗口管理。第二层是推理层,承担 Plan、ReAct、Tree-of-Thought、Reflection 这些决策范式。第三层是行动层,把模型的决策落到工具调用、函数执行、API 编排上。最下面是记忆层,包括短期上下文、长期向量库和任务级缓存。每一层都有自己的工程化坑,但只要框架对了,每一层都能独立打磨和替换。 |
| 22 | |
| 23 | --- |
| 24 | |
| 25 | # 05_three_modes |
| 26 | |
| 27 | 理解了四层骨架之后,下一个常见问题是:到底用哪种模式。简单说有三种。Workflow 是路径固定的 DAG,LLM 只负责填空,可预测、好调试,适合确定性任务。Agent 是路径动态的,运行时让模型自己决定下一步,最常用、也是大部分项目真正在做的事,适合半结构化的探索类任务。Multi-Agent 是多角色协作,把 Planner、Critic、Worker 拆开并发协作,灵活性最高,但复杂度也最高,只在真正需要长程任务的时候用。绝大多数生产场景,从 Agent 开始就够了。 |
| 28 | |
| 29 | --- |
| 30 | |
| 31 | # 06_tool_orchestration |
| 32 | |
| 33 | 把模式确定下来之后,最先开始做的就是工具编排。一个稳定的工具调用大致是六步:先解析任务、再选工具、然后调用执行、接着验证返回、必要时重试或回退、最后做结果汇总。每一步都要可观测,每一步都要有兜底。最常见的翻车点不在第一步而在第四步——大家往往拿到工具返回就直接喂给模型,缺了 schema 验证和业务规则校验,幻觉就是从这里漏进来的。 |
| 34 | |
| 35 | --- |
| 36 | |
| 37 | # 07_context_engineering |
| 38 | |
| 39 | 讲完工具,下面这页是我个人觉得最重要的一页:上下文工程。模型每天都在变,提示词也每天都在调,但真正决定一个 Agent 智不智能的,是它每一步看到了什么——也就是上下文。围绕这一个核心,至少要做好六件事:检索要稳,重排要准,截断要会取舍,记忆要分长短期,工具说明要够具体,系统提示要把人设、输出格式、安全规则都讲清楚。上下文工程做不好,模型再强也救不回来。 |
| 40 | |
| 41 | --- |
| 42 | |
| 43 | # 08_kpi_dashboard |
| 44 | |
| 45 | 接下来切到运营视角。要上生产,你必须给自己装上四块表盘。第一块是任务成功率,目前这套系统跑到了百分之九十二点四,还在每周提升三个百分点。第二块是 P95 延迟,从初版的十一秒多,收敛到了四点八秒。第三块是单次任务成本,做了模型分级路由和检索结果缓存之后,单次成本压到了四毛二。第四块是三十天 SLO 达成率,靠多模型 fallback 兜住了上游事故,目前在百分之九十九点七。这四个数没有,就别谈上生产。 |
| 46 | |
| 47 | --- |
| 48 | |
| 49 | # 09_metrics_trend |
| 50 | |
| 51 | 把这四个指标拉成时间轴,就能看到一条很真实的曲线。绿色是任务成功率,从最早的百分之七十一,一路爬到了百分之九十二点四。红色是单次成本,从一块二降到了四毛二。最关键的三个拐点都标在图上:第四周引入了 reranker,准确率跳了一档;第八周引入了 fallback,长尾任务的成本和失败率一起被压下来;第十一周引入了结果缓存,成本下了最大的一刀。每一次提升的背后,都对应一个具体的工程动作,不是靠运气,也不是靠换模型。 |
| 52 | |
| 53 | --- |
| 54 | |
| 55 | # 10_failure_modes |
| 56 | |
| 57 | 聊一聊会遇到的失败。大致可以分到四个象限。左上是高频浅层的工具错误,schema 不匹配、参数幻觉、超时无回退,这一类靠提前校验就能挡住。左下是低频但麻烦的死循环,反思链路没有终止条件,Plan 反反复复改,必须设硬性停机条件。右下是更难处理的幻觉,编造工具、编造结果,甚至假装成功,这一类只能靠 Grounding,让每一步都对接真实数据源。右上是隐蔽的成本失控,Token 漂移、重复检索、链路套娃,必须做计量和上限。预案的关键,是分类别准备,不是事后扑火。 |
| 58 | |
| 59 | --- |
| 60 | |
| 61 | # 11_roadmap |
| 62 | |
| 63 | 把这些东西整合起来,给一个十二周可执行的落地路线。第一阶段是前三周,跑通最小可用的原型,金标准 case 通过率到八成以上,再进下一阶段。第二阶段是第四到第七周,把评估集铺到一百条以上,自动回归点亮绿灯,重试和降级机制全部上。第三阶段是第八到第十周,规模化,加缓存、加限流、做多租户隔离、做模型分级路由。第四阶段是第十一到第十二周,灰度上线,从百分之一到百分之十再到全量,盯住 SLO,让飞轮真正转起来。每个阶段都要有"通关"硬指标,否则就只是在赶进度。 |
| 64 | |
| 65 | --- |
| 66 | |
| 67 | # 12_cta_closing |
| 68 | |
| 69 | 最后总结一句话。所谓的 Agent 工程化,不是给系统里加一个 LLM 就完事了,而是把 LLM 真正装进一个有架构、有上下文、有评估、有可观测的工程系统里。这四件事一起做,Agent 才能从 Demo 走到生产。希望今天分享的这套框架,能帮到正在路上的你。谢谢大家。 |
| 70 |