客服智能体上线 3 天,把 API Key 写进了日志:我补完生成式AI课后才堵住这窟窿灰度发布第 3 天,安全审计的同事在企业微信上扔过来一张截图。截图里是我们客服智能体的历史日志,明文记录着sk-proj-xxxx,OpenAI 的 API Key 像广告牌一样挂在那里。我后背一凉--这个负责退换货咨询的智能体是我牵头搭建的,另外还有两个专门处理内部知识库问答和销售周报生成的智能体。当初立项时,我们觉得 AI 开发就是调几个接口、拼几段 prompt,结果三个智能体上线不到一周就只剩一个还能用。当时我对 AI 开发的理解太浅了。我以为让模型接住用户问题是技术活,其实控制模型不乱说话、不越权、不泄露数据才是真正的工程难点。后来我停掉手里所有智能体,从头补了一门生成式AI课程,又回头啃了机器学习入门和 AWS 机器学习相关的系统知识,才把窟窿一个个堵住。如果早点正经学过这些 AI 开发基础,另外两个智能体可能不会死得那么惨。这篇文章正好把我踩过的坑、补过的课、改过的代码都列出来,给同样在摸索 AI 开发的人提个醒。三个智能体上线,为什么只活下来一个年初公司希望把 AI 开发快速落进业务,我作为技术负责人揽下了三个应用场景:客服智能体:接入电商退换货流程,自动回答客户询问知识库问答智能体:检索内部运营文档,回答员工提问销售周报生成智能体:汇总 CRM 数据生成模板化报告团队当时对 AI 开发的认识几乎停留在“调 API”层面。我们选了一个 4k 上下文窗口的模型,统一用一个简单的 fetch 脚本去调推理端点。开发两周就灰度上线,结果客服智能体第二天开始频繁输出幻觉答案,把退货地址错写成一个旧仓库。更致命的是它把 API Key 打进了标准输出,被采集日志的原样记录。知识库问答智能体更离谱,检索出来三份文档,它直接把不同内容拼接成一段逻辑不通的“科幻说明”。只有销售周报生成器因为流程固定、输出可控,勉强活着。现在回头复盘,这些翻车不是偶然的。根源就在于我们缺乏 AI 开发的系统性知识,不懂模型安全边界、不懂检索增强、也不懂成本与权限控制。第一坑:Agent 把密钥写进日志的 72 小时我们当初为了图快,在 Node.js 里直接用console.log打印了完整请求体,想着调试时方便看模型入参。结果代码写成了这样:// 危险的调试代码,上线后未删除 const response await fetch(endpoint, { headers: { Authorization: Bearer ${process.env.OPENAI_API_KEY} }, body: JSON.stringify({ model: gpt-4o-mini, messages: [...] }) }); console.log(Request payload:, JSON.stringify({ headers, body }));AI 开发中最基础的一条规则--敏感信息脱敏--我们完全没做。安全审计在监控系统里搜到密钥时,距离上线已经过去了 72 小时。这期间所有请求的 API Key 都被存进了 Elasticsearch 集群,任何有日志查询权限的人都能看到。事故发生后我找到了一门生成式AI课程,里面专门有一章讲“Agent 安全围栏”,从 prompt 注入防护、敏感信息过滤到输出审计,每个环节都有详细解释。学完这门生成式AI课程我才意识到,Agent 安全不是锦上添花,而是 AI 开发的必修课。课程里给出了一个可落地的脱敏中间件模式,我马上照着思路改了一版:// 学习后加入的脱敏与审计中间件 app.use(/api/agent, (req, res, next) { const safeHeaders { ...req.headers }; delete safeHeaders[authorization]; auditLog.write({ timestamp: Date.now(), path: req.path, headers: safeHeaders, bodyLength: JSON.stringify(req.body).length }); next(); });加完这个中间件后,日志里再也看不到密钥,同时还能保留审计所需的请求大小和路由信息。这次改动的成本几乎为零,但之前因为不懂,白白暴露了三天。第二坑:知识库问答把三份文档焊成科幻小说内部知识问答智能体用了简单的向量检索,把员工提问嵌入后,召回 top-3 文档片段,不做任何校验就直接拼进 prompt 送给模型。结果有一次行政问“年假审批流程”,系统召回了一份旧版政策、一份实习生手册和一份财务报销模板。模型面对这三段矛盾的材料,直接编造出“实习生需先报销再休假”的荒诞答复。这里暴露的是我在 AI 开发中对检索增强与提示工程的认知缺失。我根本不知道需要设置来源验证、不知道要限制模型引用超出召回范围的内容。回过头去看 AWS 机器学习系列里的机器学习入门课程,其中就用了一个电商客服的例子,手把手演示如何用 prompt 约束模型只能基于给定资料回答,超出范围就触发“无法回答”的分支。这类工程技巧正是我缺的。我把那个知识库问答智能体下掉,重新用一套结构化的 prompt 模板,配合来源标注和置信度阈值,才让回答质量回到可用水平。修改后的 prompt 模板大致如下:system: | 你只能依据下方“参考资料”中的内容回答问题。 如果用户问题无法从参考资料中得到答案,请回复“该问题暂时无法回答”。 不要在回复中编造任何信息。 在答复末尾列出引用的参考编号。 参考资料: {documents}加上这套约束后,知识库问答智能体才从“科幻作家”变回了正常的内部助手。而这套思路,很大程度来自那门机器学习入门当中对特征工程和数据处理全链条的讲解。为什么销售周报生成器活下来了三个智能体中唯一没被下线的是销售周报生成器。它没有对外接口,输入只有结构化的 CRM 数据,输出是固定字段的表格,中间不涉及自由对话和外部检索。说白了,它的 AI 开发复杂度最低,根本不需要处理复杂上下文和不确定性。这件事让我彻底想明白一个道理:在你还不能驾驭变数的时候,先只做确定性的部分。而想驾驭变数,就得系统地把 AI 开发的基础打扎实。我开始每周挤出 8 小时,从机器学习基础重新学起,跟着课程里的案例去理解什么是特征工程、数据管道、过拟合,这些原本我认为“算法岗才需要懂”的东西。只有亲自搭过端到端的机器学习管道,才能理解为什么一个看似简单的知识问答会崩盘--从数据源到召回精度,再到模型输出约束,整个链条上的任何一个环节薄弱,都可能变成线上事故。补完生成式AI和 AWS 机器学习后,我做了什么学完生成式AI课程和 AWS 机器学习相关的几门实践课后,我对当时幸存下来的周报生成器也动了刀。不是因为坏了,而是因为贵。原来我每次生成周报都要调用一次大模型,成本每天将近 180 块。学了机器学习入门里的模型选择和成本优化之后,我把大部分固定模板的生成逻辑改成规则引擎加上轻量模型,只在需要自然语言润色时才调用一次大模型。日成本从 180 块压到了 32 块,降了 82%。同时我引入了一个可观测的评估管道:每次模型输出用混淆矩阵的思路做分类--正确、轻微偏差、严重错误--自动统计并触发告警。这项改造的灵感直接来自机器学习基础知识里关于模型评估和特征数据漂移的章节。之前我只盯着准确率,没想过需要区分错误类型和代价。下表是我前后几个关键的工程变化,每一项都对应了课程里学到的知识:改动项学习前的做法学习后的做法对应课程知识密钥管理日志打印完整 header脱敏中间件过滤生成式AI的安全围栏检索增强粗暴拼接 top-kprompt 约束 来源标注机器学习入门的工程案例成本控制所有请求走大模型规则引擎 轻量模型分流机器学习基础中的模型选型输出评估只看终端是否可用混淆矩阵分类 告警AWS 机器学习中的模型监控权限隔离Agent 使用主账号 key细粒度 IAM 角色AWS 基础知识中的安全实践我的 AI 开发学习清单这趟踩坑经历让我形成了一个很明确的学习顺序,如果你也在 AI 开发上遇到过类似的问题,可以参考下面这份清单:先补齐安全与工程基础。别一上手就追求 prompt 效果,先把密钥管理、输出脱敏、权限隔离这些硬骨头啃下来。生成式AI课程里有完整的安全设计模式,值得照着演练一遍。系统走一遍机器学习管道。从数据预处理、特征工程到模型评估,每一个环节都会直接影响线上智能体的稳定性。机器学习入门用几个完整的端到端例子把这套流程串了起来,我当时花了两周仔细过了一遍,效果非常明显。掌握检索增强的边界。RAG 不是“召回生成”那么简单,需要设置来源约束、引用验证和回答拒答策略。AWS 机器学习里的检索增强实践给了一套可直接移植的模板。引入成本与评估体系。智能体一旦上线,成本会暗中膨胀,错误模式也会越来越隐蔽。机器学习基础讲清楚了如何建立混淆矩阵分类和自动监控,这些对做 AI 开发的工程师来说几乎是必修的技能。从简单场景逐步往复杂场景推。我的周报生成器之所以活着,就是因为它足够简单。在你能驾驭复杂变数之前,先用 AI 开发解决那些确定性高的问题,让团队积累经验和信心,再慢慢扩展范围。三个智能体只剩一个活着的教训,让我从一个只会调接口的工程师变成了会从安全、成本、评估全链路看 AI 开发的人。如果你现在也在搭自己的 Agent,先把这些基础课扫一遍,真的会让后面的坑少很多。