1. 从历史周期看技术浪潮的底层规律1.1 每一次技术革命都在重复同一个剧本我入行做技术差不多十二年了从早年的移动互联网浪潮到后来的云计算、大数据再到现在的大模型和智能体一路看下来最大的感受就是历史确实在重演只是换了一套名词。你去看上世纪九十年代互联网刚起来的时候企业上网的路径是什么先搞一个静态官网然后做门户再做电商最后才谈得上数据驱动。每一步都有人喊泡沫每一步也都有人赚到钱。再看二零零八年之后的移动互联网App开发从原生到混合再到跨平台工具链迭代的节奏和今天大模型工具链的迭代几乎一模一样。现在到了AI时代大模型、智能体、token、evals这些词满天飞但底层逻辑没变——新技术从实验室走向产业永远要经历“概念爆发、工具沉淀、工程化落地、成本收敛”这四个阶段。我为什么要把这个规律放在最前面讲因为很多人现在焦虑得不行觉得AI一天一个样自己跟不上就要被淘汰。但你如果拉长时间线看真正被淘汰的从来不是“学得慢的人”而是“看不懂周期位置的人”。你搞不清楚自己处在哪个阶段就会在概念爆发期盲目追热点在工具沉淀期错过真正的能力建设。1.2 当前AI落地到底处在哪个阶段我的判断是大模型本身已经过了概念爆发期正在进入工具沉淀和工程化落地的交界处而智能体还处在概念爆发期的尾巴上。证据很直接。大模型这边参数规模不再是唯一卖点大家开始比推理成本、比上下文长度、比微调效率、比私有化部署的便利性。token用量成了企业真正关心的指标因为那直接对应账单。而智能体这边各种框架层出不穷coze、hermes这类平台让搭建门槛大幅降低但真正跑通业务闭环的案例还不多大量项目卡在“演示很惊艳上线就翻车”的阶段。这个阶段定位非常重要因为它决定了你该把精力投在哪里。如果你现在还在纠结“要不要学大模型基础理论”那说明你连门都没入如果你已经在做智能体开发但还没碰过evals那你的系统大概率是“能跑但不可靠”的状态。后面我会逐个拆开讲。1.3 为什么“重演”这件事对普通从业者反而是机会历史重演意味着后来者可以站在前人的经验上少踩坑。移动互联网时代那些从PC时代过来的工程师因为理解“用户体验优先”这个底层逻辑转型做App比纯新人快得多。同样今天做AI应用如果你有过传统软件工程的经验你对“可靠性”“可观测性”“成本控制”的敏感度会比纯算法背景的人强很多。我见过太多团队模型选得很好demo跑得很漂亮但一上生产就出问题token失效导致登录失败、智能体在多轮对话中丢失上下文、evals指标好看但用户就是不买账。这些问题本质上不是AI问题是工程问题。而工程问题的解法在过去几十年的软件发展史里已经被反复验证过了。所以我的核心观点是AI时代你该做的不是抛弃过去重新学一切而是把过去的工程经验迁移到新的技术栈上同时补上AI特有的那几个关键环节。下面我就按这个思路把大模型、智能体、token、evals这几个核心概念串起来讲清楚每个环节该做什么、怎么做、容易在哪里翻车。2. 大模型选型与私有化部署的实战决策2.1 别一上来就追最大参数先算清楚三笔账我见过最典型的翻车场景一个中小团队业务需求就是做个内部知识问答结果上来就要部署最大参数量的开源模型买了两张高端显卡折腾一个月最后发现推理速度慢得没法用token成本比直接调API还贵。选模型之前你必须算清楚三笔账第一笔是效果账。你的任务到底需要多强的模型如果是分类、抽取、简单问答中等参数量的模型微调之后完全够用。如果是复杂推理、代码生成、多步规划那才需要上大模型。很多人高估了自己任务对模型能力的要求结果花了冤枉钱。第二笔是成本账。这里要区分推理成本和部署成本。推理成本按token算部署成本按硬件折旧加运维算。我一般会做一个简单的盈亏平衡计算假设你每天处理一百万token用API的价格是每百万token若干元自部署的硬件加电费加运维折算下来每天多少元。如果自部署更贵而且你没有数据隐私的硬性要求那就别自部署。第三笔是迭代账。自部署意味着模型更新、框架升级、安全补丁都要你自己扛。API调用则省心得多。如果你的团队没有专门的运维人力自部署的隐性成本会非常高。2.2 私有化部署的真实门槛在哪里企业大模型私有化部署这个词现在很热但真正做过的人知道门槛根本不在“把模型跑起来”。用开源框架拉一个模型起来半天就能搞定。真正的门槛在三个地方第一是推理性能优化。同样的模型同样的硬件不同的推理框架和量化策略吞吐量能差三到五倍。我实测过一个中等参数量的模型用默认配置跑每秒只能处理几个请求做了量化、批处理优化、KV缓存优化之后同样的硬件能扛住几十个并发。这中间的差距就是真金白银。第二是数据管道。私有化部署的核心价值是数据不出域但你的数据怎么进去、怎么清洗、怎么切分、怎么向量化、怎么更新索引这一整套管道比模型本身复杂得多。很多项目卡在这里模型部署好了但知识库更新不及时回答的内容还是三个月前的。第三是权限与审计。企业内部用不同部门、不同职级能访问的数据范围不一样。你得在推理层前面加一层权限过滤还要记录谁在什么时候问了什么、模型回答了什么。这套东西不做法务和合规那边过不了。我的经验是私有化部署项目模型选型和部署只占工作量的百分之二十剩下百分之八十都在数据管道、权限体系和运维监控上。立项的时候如果只按模型部署来估工期大概率要延期。2.3 微调不是万能药什么时候该用什么时候不该用大模型微调这个词被过度神化了。很多人一遇到效果不好就想微调但实际上大部分场景根本不需要微调。我的一般判断标准是这样的如果你的问题是模型不知道某个知识那用检索增强生成RAG比微调更合适因为知识更新方便成本也低。如果你的问题是模型输出格式不对那用提示词工程加少样本示例就能解决犯不着微调。只有当你的问题是模型不理解某个领域的语言模式或推理逻辑而且你有大量高质量的标注数据时微调才是值得考虑的。微调的坑也很多。数据质量比数据数量重要得多一千条高质量标注数据的效果可能好过一万条噪声数据。学习率、批次大小、训练轮数这些超参数对结果影响很大需要反复实验。最要命的是微调后的模型可能会在通用能力上退化也就是所谓的灾难性遗忘。所以微调之后一定要跑一轮完整的evals确认通用能力没有明显下降。2.4 模型选型的决策清单我把上面这些整理成一个可以直接用的决策清单判断维度选API调用选自部署数据隐私要求无硬性要求数据不能出域日均token用量低于盈亏平衡点高于盈亏平衡点团队运维能力无专职运维有运维团队模型更新频率需求需要紧跟最新模型版本稳定即可定制化需求提示词层面可满足需要微调或深度定制预算模式按量付费弹性前期硬件投入大这张表不是绝对的但能帮你快速排除明显不合适的选项。我自己的习惯是新项目先用API快速验证跑通业务闭环之后再评估要不要转自部署。这样风险最小迭代最快。3. 智能体开发从演示到生产的鸿沟跨越3.1 智能体不是聊天机器人加工具调用那么简单现在市面上智能体框架很多coze、hermes这些平台让搭建变得很容易拖拖拽拽就能做出一个能查天气、能搜网页的助手。但我要泼一盆冷水演示级别的智能体和生产级别的智能体差距比你想的大得多。演示级别只需要考虑“单轮任务能不能完成”生产级别要考虑的是“多轮对话中状态怎么保持”“工具调用失败怎么重试”“用户输入恶意内容怎么防护”“并发请求怎么调度”“成本怎么控制”。这些问题在演示阶段根本暴露不出来但一上线就全来了。我做过一个销售智能体的项目演示的时候一切正常能查产品库、能报价、能生成合同草稿。上线第一天就出问题用户连续问了五个问题之后智能体开始胡言乱语因为它把前面几轮的上下文搞混了。后来又发现当两个用户同时咨询同一个产品时智能体会把两个人的信息串在一起。这些都是状态管理没做好导致的。3.2 智能体架构设计的核心决策点做智能体开发架构设计阶段有几个关键决策第一个决策是单智能体还是多智能体协作。单智能体结构简单调试方便但能力上限有限。多智能体协作可以分工比如一个负责理解意图一个负责调用工具一个负责生成回复但通信开销和错误传播风险会大幅增加。我的建议是能用单智能体解决的就别上多智能体除非任务确实需要多个专业角色协同。第二个决策是工具调用的粒度。工具太粗智能体灵活性不够工具太细调用次数多token消耗大而且容易在多个工具之间迷失。我一般会把工具按业务域划分每个工具做一件事但做完整比如“查询订单”就包含根据订单号查、根据用户查、根据时间范围查这几个能力而不是拆成三个独立工具。第三个决策是记忆机制。短期记忆用对话历史长期记忆用向量数据库。但对话历史不能无限增长否则token成本扛不住而且模型注意力会被稀释。我通常的做法是保留最近若干轮完整对话更早的对话做摘要压缩后存入长期记忆需要时再检索出来。3.3 智能体容错控制的工程实践智能体自主容错控制这个说法听起来很学术说白了就是当智能体犯错时系统怎么自动发现并纠正。最常见的错误类型有三种工具调用参数错误、工具返回结果解析失败、模型生成内容偏离任务目标。对应的容错策略也不一样。工具调用参数错误比如用户说“帮我查一下昨天的订单”智能体生成的查询参数里日期格式不对。这种错误可以在工具层做参数校验格式不对就返回明确的错误信息让智能体重新生成。关键是错误信息要具体不能只说“参数错误”要说“日期格式应为YYYY-MM-DD你提供的是YYYY/MM/DD”。工具返回结果解析失败比如调用外部API返回了非预期的数据结构。这种要在工具封装层做防御性解析解析失败时返回结构化的错误对象而不是直接抛异常。智能体拿到错误对象后可以决定是重试、换工具还是告知用户。模型生成内容偏离任务目标这个最难处理。我的做法是在关键节点加一层轻量级的检查比如用一个小模型或者规则引擎判断生成内容是否包含敏感信息、是否符合格式要求、是否偏离了预设的任务范围。检查不通过就触发重新生成或者转人工。容错控制的核心原则是让错误尽早暴露、让错误信息足够具体、让恢复路径足够清晰。最怕的是错误被静默吞掉智能体一本正经地胡说八道用户还以为是真的。3.4 智能体接入业务系统的实操要点智能体客服接入千牛客户端这类需求本质上是把智能体能力嵌入到已有的业务工作流中。这里有几个实操要点第一是身份打通。智能体要能识别当前对话对应的用户身份、订单信息、历史服务记录。这需要和业务系统的用户体系做对接通常通过token传递身份信息。这里要注意token的续签和失效处理我遇到过因为token过期导致智能体突然“失忆”的情况用户体验非常差。第二是会话上下文同步。如果用户先在网页端咨询又转到客户端咨询智能体要能识别出是同一个人并且把之前的对话上下文带过来。这需要会话状态在服务端统一管理不能存在客户端本地。第三是人工接管机制。智能体搞不定的时候要能平滑转人工而且转过去的时候要把对话历史和智能体已经收集到的信息一并传给人工客服。这个交接体验做不好用户会觉得“换了个人又要从头说一遍”非常恼火。第四是回复风格适配。不同业务场景对回复风格要求不一样。销售场景可以热情一点售后场景要严谨专业内部工具场景要简洁直接。这些风格差异要通过提示词和少样本示例来调不能指望一个通用提示词打天下。4. Token机制与身份认证的避坑指南4.1 Token到底是什么为什么它总在关键时刻失效Token这个词在AI时代有两层含义很多人会搞混。一层是大模型里的token指的是文本被切分后的最小单元用来计算用量和成本。另一层是身份认证里的token指的是登录后服务端颁发的一个凭证用来证明“你是谁”。这两层含义虽然都叫token但完全是两回事。我重点讲身份认证这层的token因为这是实际项目中最容易出问题的地方。token失效、token续签失败、token exchange failed这类报错几乎每个做AI应用集成的团队都遇到过。token的本质是一段有时效性的加密字符串服务端签发之后客户端每次请求都带上它服务端验证有效才返回数据。它失效的原因通常有三种过期、被撤销、验证失败。过期最好理解签发的时候设了有效期时间到了自然失效。被撤销通常是用户主动登出或者管理员强制下线。验证失败则可能是签名不匹配、颁发者不对、受众不对等技术原因。4.2 Token续签的正确实现方式token续签的常见方案是双token机制一个访问tokenaccess token有效期短比如十五分钟到两小时一个刷新tokenrefresh token有效期长比如七天到三十天。访问token过期后客户端用刷新token去换一个新的访问token这个过程叫续签。听起来简单但实现的时候坑很多。我踩过的最典型的坑是刷新token本身也过期了但客户端没有正确处理导致用户被静默登出。用户正在填一个长表单突然提交失败提示登录过期所有输入都没了。这种体验是灾难性的。正确的做法是客户端在检测到访问token即将过期时比如剩余有效期少于五分钟就主动发起续签而不是等到请求失败了才被动续签。同时如果刷新token也过期了要明确提示用户重新登录并且在重新登录后恢复之前的操作状态。还有一个坑是并发续签。如果多个请求同时发现token过期可能会同时发起多个续签请求导致刷新token被多次使用。有些服务端的刷新token是一次性的用一次就失效这时候并发续签就会导致部分请求失败。解决办法是在客户端加一个续签锁保证同一时间只有一个续签请求在进行其他请求等待续签结果。4.3 常见Token报错排查速查表报错信息可能原因排查方向解决方案token endpoint returned status 403权限不足或来源被拒检查请求头、来源配置确认调用方权限和来源白名单token exchange failed: error sending request网络不通或地址错误检查网络连通性和接口地址确认网络可达、地址正确failed to refresh token: invalid refresh_token刷新token为空或格式错误检查刷新token存储和传递确认刷新token正确保存和读取access token could not be refreshed because logged out用户已登出检查登出逻辑是否清除了token登出时同步清除本地token并跳转登录sign-in could not be completed token exchange failed登录流程中断检查登录回调地址和参数确认回调地址配置正确、参数完整这张表是我在实际项目中遇到过的典型情况大部分token问题都能归到这几类里。排查的时候按“先看网络、再看配置、最后看代码”的顺序来效率最高。4.4 Token用量监控与成本控制大模型应用里token用量直接对应成本所以监控token用量是必须做的事。我一般会在三个层面做监控第一层是请求级监控。每次调用大模型API记录输入token数、输出token数、总token数、耗时、模型名称。这些数据汇总起来就能看出哪些功能消耗大、哪些用户用量高。第二层是用户级监控。按用户或按租户统计token用量设置配额和告警。免费用户给一个较低的配额付费用户根据套餐给不同额度。超过配额时要么限流要么提示升级。第三层是成本级监控。把token用量乘以单价算出实际成本再和预算对比。我见过一个团队因为没做成本监控一个月下来API账单比预期高了十倍原因是某个测试账号在跑批量任务时没有限制。成本控制的一个实用技巧是在提示词里明确要求模型“简洁回答”并且设置最大输出token数。很多时候模型输出一大段废话用户根本不需要白白浪费token。5. Evals体系搭建与AI系统可靠性保障5.1 没有Evals的AI系统就是在裸奔Evals这个词现在越来越热但很多人对它的理解还停留在“跑个测试集看准确率”。实际上Evals是一整套评估体系覆盖模型选型、提示词迭代、智能体行为验证、线上质量监控全流程。我为什么强调Evals的重要性因为AI系统和传统软件最大的区别是传统软件的输入输出是确定的你写个单元测试就能覆盖大部分情况AI系统的输入是自然语言输出是概率性的同样的输入可能得到不同的输出。没有Evals你根本不知道你的系统是真的变好了还是只是这次运气好。我见过一个团队提示词改了一版测试了几个case觉得效果不错就上线了结果线上用户反馈大量问题。后来一查他们测试的那几个case恰好是提示词改动覆盖到的场景其他场景反而退化了。这就是没有系统化Evals的后果。5.2 Evals体系的分层设计一个完整的Evals体系应该分三层第一层是单元评估。针对单个功能点准备一批输入输出对每次改动后自动跑一遍看通过率有没有下降。比如意图识别功能准备几百条用户问法标注正确的意图分类每次改提示词或换模型都跑一遍。第二层是集成评估。针对完整链路模拟真实用户场景从输入到最终输出全流程验证。比如智能体客服模拟用户咨询、智能体调用工具、生成回复的完整过程检查最终回复是否解决了用户问题。第三层是线上评估。在真实环境中收集用户反馈包括显式反馈点赞点踩、评分和隐式反馈是否追问、是否转人工、会话时长。线上评估的数据最真实但获取成本也最高。这三层不是替代关系而是互补关系。单元评估跑得快、成本低适合频繁迭代时用集成评估更接近真实场景适合版本发布前用线上评估最真实适合持续监控。5.3 评估指标怎么选才不跑偏选评估指标是门学问。我见过太多团队选了一堆指标跑出来一堆数字但没人看得懂也不知道该优化哪个。我的建议是指标要少而精每个指标都要能指导行动。比如准确率回答正确的比例适合有标准答案的任务相关性回答和问题相关的比例适合开放问答完整性回答覆盖了问题所有方面的比例适合多要点问题安全性回答不包含有害内容的比例所有场景都要看延迟从请求到响应的耗时影响用户体验成本每次请求的token消耗影响商业可行性指标选好之后要设定基线值和目标值。基线值是当前水平目标值是期望达到的水平。每次迭代后对比指标变化判断改动是否有效。5.4 用Evals驱动提示词迭代的实操流程我自己的提示词迭代流程是这样的第一步收集一批典型case覆盖正常场景、边界场景、异常场景。正常场景就是最常见的用户输入边界场景是那些模棱两可的输入异常场景是恶意输入或无关输入。第二步对每个case标注期望输出。期望输出不一定是唯一答案可以是一个范围或者几个可接受的答案。第三步跑当前提示词记录每个case的实际输出和期望输出对比计算各项指标。第四步分析失败的case归类失败原因。是提示词没说清楚是模型能力不够是case本身标注有问题第五步针对失败原因修改提示词重新跑评估对比指标变化。如果指标提升保留改动如果指标下降或不变回滚。第六步重复第三到第五步直到指标达到目标值或者提升遇到瓶颈。这个流程看起来简单但坚持做下来不容易。我的经验是提示词迭代最怕的是“感觉变好了”就上线一定要有数据支撑。有时候你改了一个地方感觉回答更好了但评估跑下来发现其他场景退化了整体指标反而下降。5.5 智能体行为评估的特殊考量智能体的评估比普通问答复杂因为智能体的输出不只是一段文本还包括工具调用序列、中间状态、多轮交互。评估智能体的时候除了看最终回复还要看过程。我一般会从这几个维度评估智能体任务完成率用户的问题最终有没有被解决。这个是最核心的指标。工具调用准确率该调用工具的时候有没有调用调用的工具对不对参数对不对。轮次效率解决一个问题平均需要几轮对话。轮次太多说明智能体理解能力或引导能力不足。容错能力工具调用失败或返回异常时智能体能不能正确处理而不是直接崩溃或胡言乱语。成本效率完成一个任务平均消耗多少token。有些智能体为了保险每一步都调用工具、都做检查成本高得离谱。评估智能体的时候我建议用“场景回放”的方式把真实用户和智能体的对话记录下来去掉智能体的回复让新版本的智能体重跑一遍对比新旧版本的回复质量。这种方式最接近真实场景也最容易发现回归问题。6. 多AI协作与工程化落地的个人体会6.1 多AI协作不是把多个模型拼在一起多AI协作这个词听起来很高级但实际做起来很多团队只是把几个模型串起来A模型的输出喂给B模型B模型的输出喂给C模型。这种串联结构看起来很美好实际上错误会逐级放大而且延迟和成本都是线性增长的。我理解的多AI协作应该是分工明确、各司其职、有仲裁机制。比如一个负责理解用户意图一个负责检索知识一个负责生成回复一个负责质量检查。每个模型只做自己最擅长的事最后有一个仲裁环节决定最终输出。但即便是这样多AI协作的复杂度也比单模型高一个数量级。我的建议是除非单模型确实解决不了否则不要上多AI协作。大部分场景下一个能力足够强的模型加上好的提示词工程效果不比多AI协作差而且系统简单得多维护成本低得多。6.2 AI测试开发的特殊性AI测试开发和传统测试开发有本质区别。传统测试是“给定输入验证输出是否等于预期”AI测试是“给定输入验证输出是否在可接受范围内”。这就导致几个问题第一预期输出不好定义很多AI任务的正确答案不是唯一的。第二测试用例不好设计自然语言的输入空间几乎是无限的。第三回归测试不好做模型更新或提示词改动后之前通过的用例可能失败之前失败的用例可能通过很难判断是变好了还是变坏了。我的应对策略是用评估集代替测试用例用指标代替断言。不追求每个case都通过而是追求整体指标达到目标。同时对关键case做重点监控这些case失败了要立即告警。6.3 从项目实践中总结的几条硬经验做了这么多AI项目有几条经验我觉得值得分享第一条先跑通再优化。不要一上来就追求完美架构先用最简单的方式把业务闭环跑通然后再逐步优化。我见过太多项目架构设计得很漂亮但迟迟跑不通最后不了了之。第二条监控比功能重要。功能可以慢慢加但监控必须一开始就有。没有监控你根本不知道系统在线上表现如何出了问题也不知道从哪里查。第三条成本要一开始就控制。token成本是AI应用特有的成本项如果不从一开始就控制后期很难降下来。控制成本的手段包括限制最大输出长度、缓存常见问题的回答、用小模型处理简单任务、批量处理请求。第四条用户体验的底线是“不添乱”。AI应用最怕的是自信地给出错误答案。如果模型不确定宁可说“我不确定”或者转人工也不要胡编乱造。这个原则要在提示词和容错机制里都体现出来。第五条数据是长期竞争力。模型会更新框架会迭代但你积累的用户反馈数据、评估数据集、领域知识库是别人拿不走的。从第一天起就要有意识地积累这些数据。6.4 后续可以扩展的方向这个内容后续还可以这样扩展一是深入讲RAG的工程化实践包括文档切分策略、向量模型选型、检索重排序等二是讲AI应用的可观测性建设包括日志、指标、追踪三件套在AI场景下的适配三是讲AI应用的灰度发布和A/B测试怎么在保证用户体验的前提下安全地迭代模型和提示词。这些方向每一个都值得单独展开今天先把整体框架和核心要点讲清楚。我在实际项目中的体会是AI应用落地最难的不是技术本身而是把技术能力转化为稳定的、可度量的、可持续迭代的业务价值。这个过程没有捷径就是一个个坑踩过来一个个问题解决掉慢慢积累出来的。