AI PANORAMA / TRAINING GUIDE
AI
全景洞察
从大模型到 Agent,再到企业级应用落地
面向 CXO 与技术团队的技术判断、架构方法与落地路径。重点讲清技术本质、能力边界、工程架构与企业应用。
阅读完整内容CHAPTER 01 · 03—07
AI 基础概念
一家杯子网店,看懂 AI 的五种进步
从识别投诉、看懂破损,到创建有回执的换货申请。
视频暂时无法在此播放。请下载视频后观看,或展开下方交互对比继续学习。
动手试一试:五组交互对比
01 / 从人工写条件,到从案例中学习
没说“碎了”,就不算破损吗?
客户不会照着关键词表写消息。只认“碎”和“破”的分流程序,会把一些破损投诉留给人工。
为什么会这样?展开看技术差异
回到原图:AI 包含 ML,ML 包含 DL。上面是五种瓶颈的解决思路,不是五代互相取代的产品。同一个 Agent 可以使用基于深度学习的语言基础模型,同时具备多模态和生成能力。
概念关系与原理来源
- AI 是让机器完成感知、推理、决策等智能任务的研究与应用领域。规则型专家系统与机器学习是不同路线;这里的简单关键词程序只是规则路线的入门类比。
- “大模型”强调规模;“基础模型”强调广泛预训练与跨任务复用。LLM 强调语言能力,GenAI 强调生成新内容,它们不是互斥的分类。
- 多模态强调输入或输出的信息类型;Agent 强调围绕目标,根据观察选择并执行动作的系统。现代 LLM Agent 不是 Agent 的唯一形式。
原理参考:朴素贝叶斯文本分类 · 神经网络 · 基础模型 · 工作流与 Agent
大模型的工作原理:为什么“预测下一个 Token”能产生复杂能力
预训练发生在使用模型之前。下面演示已训练好的语言模型如何生成回复;模型参数通常保持不变。
本例读取客户消息与任务要求。
切分为最小离散单元。
把符号映射到高维语义空间。
用 Self-Attention 建立长距离依赖。
计算候选 Token 的概率。
按解码策略选出接下来的片段。
把新片段加入上下文,继续生成直至结束。
- Token 是模型处理信息的最小离散单元。
- 预训练让模型获得通用语言、知识与模式能力;它是前置的训练过程。
- 上下文学习指模型利用当前提供的任务、示例等信息作答,不等于每次都重新训练。
- 推理阶段不更新参数,而是在上下文中完成条件生成。
关键认识:大模型不是在“查答案”,而是在给定上下文下做条件概率预测。
复杂能力并非来自显式规则,而是来自规模化表示学习与上下文建模。
大模型训练链路:预训练、后训练、对齐与工具化
建立通用语言、视觉和代码能力。
让模型更像一个可用的助手。
使行为更符合人类偏好和任务目标。
强化工具调用与结构化输出能力。
通过数据、提示、检索或微调适配业务。
- 通常不需要重做预训练。
- 重点在后训练使用能力与业务域适配。
- 工具调用与评测决定可用性。
企业应用更关注“怎么把模型用好”,而不是“怎么重新训练一个基础模型”。
大模型能力边界:擅长什么,不擅长什么
擅长
- 语义理解与信息归纳
- 文本、代码、图像等内容生成
- 知识重组、摘要、改写、问答
- 在有限上下文内进行近似推理
不擅长 / 高风险
- 精确计算与严格符号推导
- 强确定性事务逻辑
- 长链路任务中的稳定状态管理
- 事实长期一致性与零幻觉输出
把大模型当作概率引擎使用,并用外部系统提供约束与校验。
从模型能力到系统能力:为什么必须系统化
- 企业 AI 不只是调用一个模型
- 效果由上下文组织和工具接入共同决定
- 可用性取决于流程编排与异常处理
- 上线能力依赖评测、观测和回归机制
- 规模化运行必须具备权限、安全与成本治理
权限 / 安全 / 审计 / 成本
Eval / Replay / Trace
Workflow / Agent Loop
搜索 / 数据库 / API / 执行器
Prompt / 检索 / 会话状态
LLM / VLM / Embedding
企业落地的核心对象不是单个模型,而是一套可控、可评估、可迭代的 AI 系统。
CHAPTER 02 · 08—13
AI 技术洞察
沿技术栈判断企业真正需要建设哪一层
通用 LLM、代码模型、多模态模型和 Embedding 是技术底座。企业通常通过模型网关统一接入,而不是重复训练基础模型。
RAG 补充私有知识,Tool Use 连接真实系统,Memory 保存必要状态,Guardrails 约束权限与风险。
Workflow、Agent Runtime、评测、观测、权限和成本管理,把一次模型调用变成稳定、可追踪的生产系统。
知识助手、开发助手或业务 Copilot 只是交付形态;是否有价值,要回到流程效率、质量和业务指标验证。
当前主流 AI 技术栈全景
知识助手 / 开发助手 / 运营助手 / 业务 Copilot
Prompt 管理 / 评测 / 观测 / 权限 / 成本
Workflow / Agent Runtime / Multi-Agent
RAG / Tool Use / Memory / Guardrails
通用 LLM / 代码模型 / 多模态模型 / Embedding
真正需要建设的,往往不是最底层模型,而是中间能力层与平台层。
RAG、微调、Workflow、Agent:到底该怎么选
选型取决于任务开放度与流程确定性,而不是技术热度。
知识更新、事实补充、企业知识接入。
开放任务、动态决策、多工具协同。
风格、格式、领域习惯与小范围能力偏移。
路径固定、规则清晰的稳定流程。
- 能用 RAG 的,不必先做微调。
- 能用 Workflow 的,不必强上 Agent。
- 多数企业主流组合:RAG + Workflow + 少量 Agent 化。
不要把所有问题都交给 Agent,技术选型应与任务结构匹配。
上下文工程:决定 AI 系统效果的关键变量
定义角色、边界与输出要求。
通过示例稳定行为模式。
把外部知识注入当前上下文。
补充任务态、用户态、组织态信息。
把执行结果重新注入模型。
控制长期信息保留与更新。
很多效果问题,并不是模型差,而是上下文组织方式差。
提示词只是上下文工程的一部分,真正关键是信息如何被组织并进入模型。
多模态技术正在改变什么:从文本理解到真实世界感知
多模态让 AI 不再只读文字,而是理解更丰富的业务信息,驱动更可靠的决策与执行。
PDF、表格、票据、规范、图纸解析。
质检、截图理解、设备状态识别。
会议、客服、现场语音交互。
巡检、安防、操作过程分析。
- 价值不只是“看懂图片”,而是把感知输入转成流程可处理的信号。
- 企业价值来自多模态与流程、系统、规则的结合。
多模态正在把 AI 从文本助手扩展为可感知真实业务环境的系统能力。
AI 成本与性能的真实约束:为什么“能跑”不等于“能规模化”
Token 费用 / 模型单价 / 长上下文成本
首字延迟 TTFT / 全部输出 TPOT / 用户体验
高峰流量 / 队列等待 / 资源调度
检索、数据库、日志、工具调用、缓存
监控、回放、回归、模型切换、故障处理
规模化可用性 =(效果 × 稳定性)/ 单位成本
- 模型越大效果可能更好,但延迟与成本更高。
- 链路越复杂能力更强,但失败点更多。
- 真正上线比拼单位成本下的稳定效果。
企业最终竞争的不是单次演示效果,而是可持续、可观测、可规模化的运行能力。
安全、治理与合规:企业 AI 不能绕开的底线工程
一旦 AI 连接企业数据与业务动作,治理就必须成为架构的一部分。
- 敏感信息泄漏
- 越权访问
- 数据隔离与脱敏
- Prompt Injection
- 越狱
- 恶意工具调用
- 有害输出
- 偏见与不当建议
- 事实错误传播
- AI 建议边界
- 人工复核
- 业务责任归属
安全与治理不是上线后补救,而是从设计阶段就应内建在 AI 系统中的底层能力。
CHAPTER 03 · 14—20
AI Agent 发展
一个可上线的 Agent 循环必须回答四个问题
把用户请求转成可验证的完成条件,同时记录权限、时间、成本和禁止动作等约束。
根据当前状态选择检索、调用 API、请求审批或直接输出;复杂任务再拆分,简单任务不必强行规划。
Observation 需要校验状态码、数据完整性与业务规则。工具返回成功,不代表业务目标已经达成。
设置成功条件、失败分级、重试次数和循环上限;高风险动作进入人工审批,避免无限循环与误操作。
设备异常处理:读取告警 → 检索设备手册与历史工单 → 生成排查计划 → 查询实时状态 → 给出处理建议 → 人工确认后创建工单 → 回写处理结果。
为什么进入 Agent 化阶段:从会回答到会行动
Agent 并不是突然出现的新概念,而是模型、工具与编排能力逐步成熟后的系统形态。
更稳定地理解任务与输出结构
函数调用 / API 调用 / 外部执行
处理更长链路任务
支持编排、状态管理与循环
企业希望 AI 不只回答,而是参与执行
关键判断:Agent 的本质是把模型嵌入执行闭环;Tool + Memory + Planning 让 AI 从回答走向行动。
Agent 化的起点不是更会聊天,而是能够围绕目标进行感知、决策与执行。
Agent 的核心运行机制
- 01接收任务
- 02解析目标与约束
- 03分解子任务 / 规划
- 04选择知识 / 工具
- 05执行 Action
- 06读取 Observation
- 07判断是否完成 / Evaluation
真正可用的 Agent,不是多想一步,而是能在循环中持续修正并推进任务完成。
Agent 的关键构件
推理与生成核心
短期 / 长期记忆
搜索、API、数据库、执行器
任务分解与计划
步骤状态与上下文
安全边界与规则校验
没有记忆、工具、状态与约束,很多系统只是高级 Prompt,而不是完整的 Agent。
Workflow 与 Agent 的本质区别
节点固定,路径清楚
路径动态,决策自主
规则显式,易于控制
依赖模型理解与工具选择
可预测性高,稳定性强
结果不确定,需要反馈机制
易测试、易监控、易治理
需要更强的观测与约束
标准流程、审批、固定任务、规则明确业务
开放任务、多工具协同、复杂环境中的决策
企业实践:以 Workflow 为骨架,Agent 处理不确定与复杂部分。
Workflow 与 Agent 不是互斥关系,最常见的企业实践是前者兜底、后者增强。
单 Agent、多 Agent 与 Agent 平台
角色数量并不是重点,复用、治理与工程化能力往往比“多几个 Agent”更重要。
- 处理单一任务流程
- 结构简单,易部署
- 适合个人助手、Copilot、问答、工具调用
- 角色分工,协同完成复杂任务
- 规划、检索、执行、审查分工
- 适合多步骤任务与复杂链路
- 统一模型、工具、知识与权限
- 提供评测、观测、发布、审计能力
- 支撑组织级复用与规模化落地
多 Agent 不等于更好,平台能力决定可复制与可治理性。
企业更需要的是可复用、可管理、可演进的 Agent 基础设施,而不只是几个新角色。
Agent 的失败模式
常见失败
- 目标理解错误
- 工具或参数选择错误
- 中间状态丢失
- 长链路误差累积
- 幻觉结果被后续步骤放大
- 无法稳定结束或反复循环
工程化应对
- 步骤可观测:日志与轨迹
- 失败可重试:错误分类
- 关键步骤可人工介入
- 设置停止条件与循环上限
- 输出与业务规则校验
没有工程化的 Agent = 不稳定的黑箱
Agent 不能直接裸奔上线,必须配套评测、观测、异常处理与人工兜底机制。
企业级 Agent 平台需要哪些底座能力
真正决定 Agent 能否复用、治理和扩展的,往往不是模型本身,而是平台底座。
目标:构建一套可复用、可治理、可观察、可迭代的 Agent 基础设施。
平台化不是额外包装,而是把零散 Agent 应用转化为组织级能力资产的关键步骤。
CHAPTER 04 · 21—24
AI 开发的工程方法
沿一次请求理解企业 AI 架构的职责边界
- 01应用层接收业务任务
页面或业务系统提交任务,同时带上用户身份、场景和必要的业务参数。
- 02平台层执行统一治理
完成身份校验、权限判断、模型策略、成本策略,并为本次请求建立 Trace。
- 03能力层组装执行链路
检索知识、选择工具、维护状态并按 Workflow 或 Agent Loop 推进任务。
- 04模型层完成理解与生成
通过 Model Gateway 选择合适模型;模型只处理适合概率生成的部分,确定性动作仍由工具执行。
- 05结果回到评测与观测
记录答案、引用、工具轨迹、耗时、成本和反馈,形成可回放的数据资产。
AI 开发范式变化:从“写功能”到“构建可调优系统”
传统软件开发
- 明确需求
- 规则 / 逻辑显式
- 确定性输出
- 测试以覆盖逻辑为主
AI Native 开发
- 概率模型 + 上下文
- 工具编排 + 工作流
- 输入不确定,需要评测闭环
- 测试以效果为主
- 持续观测与迭代优化
代码不再是唯一资产 · 数据 · 提示 · 工具 · 评测集 · 日志
AI 应用开发的核心对象,不再只是代码本身,而是一个可调优、可观测、可持续改进的系统。
AI 应用开发生命周期
企业 AI 应用不是一次性上线,而是快速验证、持续迭代、逐步扩大覆盖面的过程。
- 01场景选择与价值定义识别高价值场景;明确目标与指标
- 02任务拆解与输入输出拆解业务流程;定义输入与输出
- 03提示与上下文设计设计模板;构建上下文与约束
- 04知识与工具接入接入 RAG;连接工具与 API
- 05原型验证实现原型;验证业务价值
- 06评测集构建建设数据集;确定指标与基线
- 07灰度上线小范围试点;监测效果与风险
- 08线上观测与迭代建设指标与告警;持续优化
快速验证价值 · 持续迭代优化 · 逐步扩大覆盖
AI 项目不应先做大而全平台,而应先围绕高价值闭环任务完成验证与复制。
评测体系:没有 Eval 就没有可靠的 AI 系统
效果不能靠主观判断,需要通过评测集、线上观测与反馈闭环持续验证。
评测维度
准确性、完整性、幻觉率、工具调用成功率、步骤正确率、延迟(TTFT / TPOT)、成本($/call)、用户满意度、业务指标。
离线评测
- 标准集
- 回放集:线上真实问题
- 对抗集
- 工具 / 函数单元测试
在线评测
- A/B
- 人工抽检
- 日志回放
- 用户反馈闭环
持续、可回放、可比较的评测体系,是把 AI 应用从 Demo 推向生产的基础设施。
AI 应用的参考架构
分层解耦可以提升复用、治理与迭代效率,也便于按需替换模型与能力组件。
知识助手 / 开发助手 / 运营助手 / 业务 Agent / …
Prompt 管理 / 评测 Eval / 观测 Trace / 权限与审计 / 成本管理
RAG / 检索 / Memory / Tools / Workflow / Agent Runtime / Guardrails
LLM / 多模态模型 / Embedding / ASR / TTS / Model Gateway
分层解耦、能力可复用,便于治理与演化。
企业真正要建设的,不只是单个应用,而是一套可复用、可治理、可持续演进的 AI 能力底座。
CHAPTER 05 · 25—27
AI 应用场景
用可验证的小闭环完成第一次试点
优先选择已有操作流程和历史样本的任务,例如工单分类、报告初稿、知识检索,不从完全自治决策开始。
至少明确人工耗时、一次通过率、错误率和处理量,否则上线后无法证明 AI 是否真正创造价值。
规定哪些动作只建议、哪些可以自动执行、哪些必须审批,并为数据权限和工具调用留下审计记录。
将有效的提示模板、知识源、工具接口、评测集和失败案例标准化,再复制到相邻场景。
通用企业场景
内部知识检索、问答、文档理解
代码生成、单元测试生成、代码解释
摘要、润色、续写、自动化报告
智能客服、工单处理、应答建议
数据解读、洞察、预测、汇报
表单、审批、任务执行
核心价值:提升非结构化信息与知识密集型工作的效率和质量。
企业 AI 最先创造价值的,通常不是完全自治,而是人机协同增强型场景。
制造与运营场景:Agent 如何嵌入业务链条
设备数据、图纸文档、工单日志、质检图像、语音记录
理解、整理、检索、判断、执行建议
MES / ERP、EAM / 设备管理、工单系统、知识库
工单生成、异常处理、报告输出、反馈闭环、策略优化
关键是把 AI 嵌入真实运营节点,形成“感知—决策—执行—反馈”闭环。
制造场景的落地重点,是把 AI 能力嵌入实际业务链条,而不是停留在问答入口。
从试点到规模化
- 单点提效
- 个人和团队使用
- 验证价值与可行性
- 标准化场景
- 形成专用产品
- 复制到同类业务
- 统一模型与权限
- 服务化与组件化
- 建设方法与资产
- 流程与岗位重构
- 数据协同沉淀
- AI 融入决策
规模化难点:组织协同、流程再造与能力持续建设。
真正的壁垒不在做出 Demo,而在持续复制、治理与演进能力。
28 / CONSENSUS
总结:构建企业级 AI 系统的关键原则
把 AI 看成系统工程,而不是单一模型采购,是企业实现长期价值的前提。
- 01
以业务价值为导向:聚焦高价值、可闭环的问题。
- 02
先系统化思维:把模型、工具、数据、评测视为一个系统。
- 03
优先建设能力中台:上下文工程、工具工程、评测工程。
- 04
可观测与可迭代:用数据驱动优化,而不是凭感觉。
- 05
安全与治理先行:权限、审计、合规不可缺。
- 06
长期主义:持续投入数据、知识与平台能力。
AI 不是替代,而是增强;不是炫技,而是创造可衡量的价值。
回到顶部