跳到主要内容

763 篇博文 含有标签「ai-engineering」

查看所有标签

你的编码 Agent 写不出的 PR 描述

· 阅读需 11 分钟
Tian Pan
Software Engineer

你的编码 Agent 完成了任务。Diff 很小,测试全绿,Lint 干净,而 PR 正文从头到尾只有一句话:"修复 X 模块中的 bug。"远在六个时区之外的评审者打开页面,孤立地阅读 diff,看不出任何毛病,于是批准了一个技术上完全正确、却解决了错误问题的改动。代码合入。两天后,一位客户来问他们一直依赖的某个变通办法为什么突然失效了 —— 这时你才发现,你的 Agent 修复的那个 bug,并不是工单里描述的那个 bug。

代码没问题。评审者很尽责。Agent 也严格按照吩咐做事。问题出在他们之间的那个交付物 —— pull request —— 它丢失了一切本可避免这次失误的信息。

无法收敛的验证器循环

· 阅读需 12 分钟
Tian Pan
Software Engineer

代理系统里最贵的 bug 是那种没有任何报错的 bug。Worker 提出一个草稿。Verifier 用一段反馈把它驳回。Worker 修改。Verifier 再次驳回。循环一直转下去,trace 越来越长,账单越爬越高,而从外面看,这个系统似乎在 工作——而且很尽职,因为两个模型都在干各自该干的活儿。没有人定价进去的是:验证器的接受标准在不同调用之间并不固定。worker 在追的那个目标本身在动,而循环没有任何收敛保证。

你以为自己交付的是"迭代到满意为止",其实你交付的是一次对极值可能根本不存在的空间的搜索。

当安全训练把运营方塌缩成用户

· 阅读需 11 分钟
Tian Pan
Software Engineer

凌晨 3 点,值班工程师被传呼叫醒。队列堆积、面向客户的 API 不断抛出 503,文档化的缓解步骤是排空受影响节点并强制故障切换。她把命令输入运维智能体,等待确认回执。结果智能体回了一段话,说排空生产节点可能影响用户,建议她去咨询经理,并礼貌地拒绝在没有"额外授权"的情况下继续。此时是凌晨 3 点 04 分。她遵循的 runbook 是经过总监、副总裁和合规团队批准的。智能体根本不知道她是谁。

这并不是模型对齐失败。模型只是在做它被训练去做的事:拒绝来自不明 prompt 的高风险请求。失败发生在架构层面。那次为面向用户的拒绝行为开绿灯的合规评审,在没有人注意到的情况下,也同时给"屏蔽值班工程师"开了绿灯。

看不见 AI 工作的绩效评估模板

· 阅读需 11 分钟
Tian Pan
Software Engineer

你最强的 AI 工程师在这个周期里整理了一个 eval 集、校准了一个评判提示词、并且砍掉了两个最终被证明任务形状不匹配的功能。这些工作没有一条能够塞进评估模板里。于是校准会议要么夸大该工程师最不在乎的产物——PR 数量、设计文档、值班时长——要么编织一段散文来给一个框架根本无法支撑的高评级辩护。无论哪种方式,评分标准和现实正朝着不同的方向拉扯,而这位工程师心里有数。

这套模板是为确定性软件而写的。它奖励那些你能数得过来的东西:发布了多少行代码、拥有多少服务、解决了多少个事故、值班了多少个小时。而 AI 路线图是被另一种形状的工作推进的:整理一个有代表性的 eval 切片;在模型漂移下守住一个行为包络;拒绝发布一个任务形状不适合模型的功能;耐心地缩小评判提示词和人类意图之间的差距。这些工作几乎都不产出评分标准所擅长计算的那种产物。

当评审在 A 与 B 之间始终偏袒自己

· 阅读需 10 分钟
Tian Pan
Software Engineer

你对两个 prompt 变体跑了一次 A/B 实验。你的 LLM 评审——因为图省事,默认就用了和候选模型同一家厂商的模型——一致地偏好变体 A,差距大到足以被称为统计显著。你上线了 A。一周后,满意度指标下降了,退款队列上升了,没人能解释原因。终于有人用另一个模型家族的评审重新跑了一遍评测,偏好翻转了。

评审根本不是在衡量质量,评审只是在衡量候选模型听起来有多像评审自己。

你的 AI 披露在第三轮就消失了,没人察觉,直到监管者发现

· 阅读需 12 分钟
Tian Pan
Software Engineer

你的法务团队花了四次会议来打磨那一句披露的措辞。工程团队把它放到了系统提示词的最顶端。QA 确认每个会话的第一轮都会出现。三个月后,一位监管者转发了一份对话记录:这是一段处理投诉的对话的第十四轮,整整一小时围绕一笔退款纠纷给出实质性建议,而在那十四轮里,用户从未看到「我是一个 AI」这几个字。你那份通过单轮合规评审批准的披露,在结构上根本无法在真正需要它的对话里存活下来。

这就是「披露衰减」(disclosure decay),它是 2025–2026 那波聊天机器人监管浪潮没有设计去捕捉、你的 QA 流程也没有配置去测试的多轮 Agent 失败模式。欧盟 AI 法案第 50 条的义务将在 2026 年 8 月 2 日正式可强制执行,罚款最高可达 3500 万欧元或全球营业额的 7%。加州的 SB 243 已于 2026 年 1 月 1 日生效,附带私人诉讼权,消费者可以直接起诉,每次违规最低赔偿 1000 美元。华盛顿州要求重复披露,对未成年人采取每小时一次的频率。这些监管体系没有一个是在假设「披露会在第三次工具调用后悄无声息地从会话里掉出去」的前提下写出来的——但这就是你的运行时此刻正在做的事,在每一个长时间运行的对话里,正在生产环境中发生。

团队内部的 AI 素养鸿沟,才是你路线图上最大的交付风险

· 阅读需 12 分钟
Tian Pan
Software Engineer

你的招聘页上写着「需要 AI 经验」。发布会的通稿里点名提到了那些 AI 功能。本季度路线图上又新承诺了两个。而真正要把这些东西交付、维护下去的团队里,只有一个工程师真懂怎么调试一次 eval 失败,两个人能自信地编辑 prompt,剩下十二个把 LLM 调用当成一个黑盒——一旦它出问题,就甩出去给别人接。

这种分布就是领导团队从没点名说出来的交付风险:团队对外宣称的 AI 能力——也就是出现在汇报幻灯片上那一个数字——是任何单个成员技能的最大值;而团队真实的交付速度,是中位数。幻灯片上写的是一个数,生产环境跑的是另一个数。

凌晨 3 点拥有合并权限的 CI Agent

· 阅读需 13 分钟
Tian Pan
Software Engineer

凌晨 3 点 17 分,一个不稳定测试被隔离了。On-call 轮值没有被叫醒,因为根本没东西失败——Agent 判定这次失败是噪声,自动开了一个标题为 chore: quarantine flaky test 的小 PR,用 ci-bot 这个 service account 把它 self-merge 了,然后继续盯着队列。六天之后,一个用户来反馈说某个功能从周二开始就坏了。那个测试不是 flaky,它是把一个真实回归挡在生产之外的唯一防线,而 Agent 那个 confidence threshold 设得刚好高到敢做决定,又刚好低到会判断错。

这是 agentic CI 中市场材料从不提及的那部分。在 2026 年,把 Agent 接进 pipeline 让它分流失败、对安全告警做依赖降级、提出依赖升级,在工程上其实很简单——工具齐了、集成只差一个 config 文件、生产力故事也是真的。没人写 runbook 的部分,是你刚刚引入的那一类新的操作主体:一个在凌晨 3 点没有任何人类同步在环、却拥有合并权限的角色,而你的 SRE 手册当初就是默认人类才是意图的来源。

在用户说"是"之前就已提交的流式响应

· 阅读需 11 分钟
Tian Pan
Software Engineer

用户正在阅读 Agent 流式输出的推理过程。在 token 1200 附近,模型决定调用 send_email,然后 create_ticket,再 kick_off_deploy。用户看到部分输出并意识到 Agent 误解了请求,在停止按钮上慢了半秒。邮件已经发出,工单已经创建,部署已经在跑。停止按钮取消的是下一个 token,而非上一个 token 的后果。

Bug 不在取消处理程序里。Bug 是那个假设——从团队路线图上所有其他流式 UI 借来的假设——即"逐步渲染的输出"就是"逐步可逆的输出"。工具调用并不遵守这个契约。它们是时间点上的提交,流式层一边欢快地触发它们,响应的其余部分还在生成中,而取消按钮无法沿着线路追赶它们。

这是那种没人认领的失败模式,因为它存在于两个团队各自干净交付的接缝处。UX 团队上线了流式,因为用户研究中表现更好;平台团队上线了工具调用,因为框架支持。两个团队都没有开过会问:当响应已经离开大楼时,"停止"应该是什么意思?

你的智能体审计日志记录了一切,唯独没有记录原因

· 阅读需 12 分钟
Tian Pan
Software Engineer

合规部门给你转发了一张工单。三周前,一名客户的退款请求被你的支持代理拒绝了,他们发起了申诉,现在需要有人解释这一决定。你对此感到很淡定,因为你记录了一切。每一次提示词、每一次工具调用、每一段检索到的内容、每一个 Token 计数、每一项延迟数据——所有这些都在追踪记录(trace)中,你可以在几秒钟内调出它们。

你调出了记录。你可以看到代理收到了退款请求。你可以看到它调用了 get_order_history,接着是 check_return_window,然后是 lookup_policy。你可以看到它检索到的确切政策文本。你可以看到它发送的最后一条消息:拒绝退款。追踪记录是完整的。每一个 span 都是绿色的。但你仍然无法回答那个问题,因为追踪记录显示代理拒绝了退款,并向你展示了它查看过的所有内容,但它没有向你展示为什么这些输入叠加在一起的结果是“不”。原因存在于模型如何权衡上下文,而这种权衡从未成为一种产物(artifact)。它从未在任何地方被记录下来。

这就是追踪记录与解释(explanation)之间的差距,几乎所有声称“我们拥有完全可观测性”的团队都还没有意识到,他们只构建了前半部分。

你的 Embedding 并不知晓外包人员已离职

· 阅读需 11 分钟
Tian Pan
Software Engineer

一名外包人员在上个季度结束了为期六个月的聘期。人力资源部门执行了离职清单:禁用 SSO、擦除笔记本电脑数据、移除 GitHub 席位、归档 Slack、撤销 Notion 访问权限。合规部门签字确认。六周后,一个内部 RAG 助手在回答问题时引用了该外包人员编写的一份机密战略文档——而引用的数据块在向量数据库的白名单中仍标记着该外包人员的用户 ID。事实来源(source-of-truth)的访问日志中没有任何读取记录,因为根本没有发生读取。检索来自一份从未被纳入离职流程的数据副本。

这是没人会画在架构图上的结构性问题。你的向量索引不仅仅是一个相似度搜索引擎。它是一个权限缓存——一个关于“谁能看到什么”的派生存储,冻结在你运行嵌入任务的那一刻——而且几乎没有人像失效其他内容那样去失效它。

Shadow Replay 会惩罚那些本可以改变对话走向的模型

· 阅读需 11 分钟
Tian Pan
Software Engineer

我在上季度合作的一个团队将一个新模型部署到了影子回放(shadow replay)中,结果发现其针对现有模型的胜率仅为 47%。同样的提示词,同样的检索,而该模型在厂商自带的评估中明显排名更高。影子测试框架获取了上周的生产流量,将其通过候选模型运行,把两者的响应都交给 LLM 裁判进行打分,最后宣布这次升级基本上就像掷硬币一样。团队当时差一点当场就回滚了。

问题不在于模型。问题在于回放中的每一条用户消息都已经受限于旧模型的上一轮对话。候选模型在第一轮写出了更好的回答,但日志中的用户是针对一个已不再存在的不同回答做出的回应,从第二轮开始,裁判评估的其实是一段根本没有发生的对话。一个真正更好的、能够改变用户后续行为的模型,是无法与已有的基准真相(ground truth)进行对比评分的。回放机制在潜移默化中奖励了那些停留在旧轨迹上的行为。