工程实践

最开始，我只是想把几个并行任务分开。 一个负责找方向，一个盯产品，一个审代码，再找一个专门挑错。这样一来，我不用在一个超长对话里反复切换上下文，每个任务也能有自己的责任人。 后来有一天，我看着 Codex 侧边栏，发现里面已经有了 COO、产品负责人、技术负责人、发布验证工程师和内容秘书。再往下翻，还有一批临时研究员、接任者和组长。 我干脆给这套东西起了个名字：Aimake / 爱创，一家虚拟 AI 公司。 这是缩编之后的团队。截图是我真实使用的 Codex 项目列表，不是为了文章补画的组织图。 听起来有点像角色扮演，但真正做起来以后，它更接近一次小型的组织实验：我既是投资人，也是 CEO；AI COO 负责派单和收口；下面的人各自做产品、技术、验证、研究和内容。 实验做了一阵，我得出的第一个结论并不浪漫：启动 Agent 很容易，管理 Agent 很难。 我为什么要把任务变成“岗位” 只开一两个 Codex 任务时，管理基本不是问题。我自己记得每个窗口在干什么，也知道哪段结论值得信。 一旦任务变多，情况就变了。 每个 Agent 都能写计划、搜资料、跑测试，也都很擅长交出一份看起来很完整的报告。但报告多，并不代表事情更清楚。我开始反复遇到三个问题： 大家研究的是不是同一件事？ 它说“完成了”，到底完成到哪一层？ 哪些动作可以自己做，哪些必须停下来等我？ 所以我没有继续靠聊天记忆维持秩序，而是给任务加上了岗位、汇报线和验收人。 每次派单尽量写成一张很短的合同： 1 2 3 4 5 6 7 目标：这次只解决什么？ 交付：结束时必须留下什么？ 事实源：以哪些代码、文档或运行结果为准？ 完成门：满足什么才算完成？ 停止门：出现什么情况立刻 Hold？ 接收人：谁来复核和采用？ 外部权限：哪些动作必须等我批准？ 这比“认真调研一下，给我一个完整方案”有用得多。后者很容易得到一篇漂亮长文，前者才有机会得到一个能被下一位接住的结果。 然后我还是扩编过头了 这次集中冲刺里，我想同时看清产品方向、用户证据、技术架构、开源交付、安全风险和内容增长，于是短时间拉起了数十个任务。 一开始感觉非常好。屏幕上到处都在动，每隔几分钟就有新发现。不同角色从不同角度挑问题，很多盲点确实比我一个人顺序做更早暴露。 但热闹持续了一会儿，代价就出来了。 有人在重复研究同一个问题；同一款产品收到几份彼此冲突的优先级建议；上一份报告还没写完，接任它的任务已经开始；自动测试通过、真实环境可用和用户愿意复用，被几份汇报写成了差不多的“完成”。 最尴尬的是，每个 Agent 都能证明自己做了很多，却没人能证明公司应该因此改变哪个决定。 峰值时，我设置了五个临时组长，让他们吸收大约二十五个成员任务。等真正开始汇总，完整交付并被采用的只是一小部分。其余内容有的重复，有的只是阶段记录，有的结论已经被后来的验证推翻。 那一刻我才承认：我扩大的不是产能，至少不全是。很大一部分只是管理复杂度。 收工不是一句“停”，而是一场交接 我没有马上把所有任务关掉，也没有让旧岗位突然消失。 先冻结新增范围，让每个人把眼前能够安全收口的工作做完；再留下有效事实、失败记录、未知项、恢复路径和下一道门槛；接收人能够复述并独立继续之后，旧任务才归档。 ...

一个用 AI 写代码的开发者,现在一天能开五六个 PR。 而审你 PR 的那个人,一天还是只能审五六个。 这两个数字凑在一起,就是 2026 年大多数工程团队真正的麻烦。Faros AI 的数据里,高 AI 使用率的团队完成的任务多了 21%、合并的 PR 多了将近一倍,但 PR 的 review 时长涨了 91%——而且那些 PR 还更大。Opsera 一份覆盖 25 万开发者的报告说得更直白:在没有治理的情况下,AI 生成的 PR 在 review 队列里等的时间是普通 PR 的 4.6 倍,哪怕从写完到提 PR 的时间砍掉了一半多。 写代码这件事,被 AI 解决了一大半。审代码这件事,一点没变。瓶颈就这么从「写」挪到了「审」,而且大多数团队还没意识到。 为什么 AI 写的代码,审起来反而更难 直觉上,AI 代码该更好审才对——它风格统一、不会忘加分号、命名规规矩矩。但真审过 AI 大批量产出的代码的人都知道,事情反过来了。AI 代码难审,难在三个地方。 第一,它看着太合理了。 人写错代码,常常会留下「破绽」——变量名词不达意、缩进乱、注释和代码对不上,这些视觉信号会让 reviewer 警觉。AI 不会。AI 写的错误代码,长得和正确代码一模一样:命名得体、结构清晰、注释贴心。CodeRabbit 的研究说 AI 写的代码暴露的问题比人写的多 1.7 倍,而这些问题里相当一部分是逻辑错误——业界一个被反复引用的说法是,AI 代码的纯逻辑错误率比人高约 75%。一个长得人模人样的函数,你的大脑会默认它没问题,于是真正的 bug 藏在「看着合理」的外壳里溜过去了。 第二,量。 一个 reviewer 以前一天面对的是三五个 PR、每个两三百行。现在是十几个 PR,而且单个更大。注意力是有总量的——审第一个 PR 时你逐行读,审到第八个时你已经在「扫」。Review 质量不是匀速下降的,是过了某个阈值之后断崖式塌掉的。量本身就是一种攻击。 ...

先说一个反常识的事:大多数团队的"第一个 LLM 网关"不是装出来的,是不知不觉写出来的。 最初你的代码里只有一句 openai.chat.completions.create()。后来 OpenAI 半夜抽风,你在外面包了个 try/except,失败就调 Anthropic。再后来财务问"这个月十几万的 token 花在哪了",你又加了一段记账逻辑。再后来某个客户的流量把你的限额打爆,你又写了个令牌桶。 这些 if/else 散在三个仓库、五个文件里,没人敢动。这就是网关——一个没有名字、没有人维护、谁碰谁倒霉的网关。 所以问题从来不是"要不要 LLM 网关",而是"这层东西,是攒成一坨烂代码,还是收拢成一个能被维护的组件"。这篇就讲清楚:它到底该管什么、自建还是用现成、路由策略怎么定,以及它本身会带来什么麻烦。 网关到底替你扛了什么 把它想成 LLM 调用的反向代理:你的应用只跟网关说话,网关再去跟一堆模型供应商打交道。它该扛七件事,但这七件事的优先级差得很远。 能力 解决什么 优先级 统一 API 一套 OpenAI 格式的接口调所有模型,换模型不改业务代码 必须 故障转移 某家供应商挂了 / 限流了,自动切到备用 必须 密钥管理 上游真 key 收在网关,业务侧只发"虚拟 key" 必须 限流配额 按 key、按团队、按租户限 QPS 和预算 高 成本核算 每次调用算钱,按业务线 / 用户出账单 高 可观测 全量请求日志、延迟分位、错误率、token 用量 高 缓存 命中过的请求直接返回,省钱省延迟 看场景 前三个是"接了第二个模型就立刻需要"的。中间三个是"上了生产、有了多个调用方"之后绕不开的。最后一个——缓存——别一上来就上,后面单独说。 统一 API 是地基。2026 年的事实标准是 OpenAI 的 /v1/chat/completions 格式:几乎所有网关都对外讲这套协议,对内再翻译成 Anthropic、Gemini、Bedrock、火山引擎、通义各自的方言。好处很直接——你的业务代码里不该出现任何一家供应商的 SDK,只有一个 base_url 指向网关。换模型这件事,从"改代码、过测试、发版"变成"网关上改一行配置"。 ...

先说一个数字:同样问"帮我查一下这个 bug",发给聊天机器人和发给 Agent,token 消耗能差 50 倍。 聊天机器人就一来一回:你发一段、它回一段,结束。Agent 不一样——它跑的是一个循环:看任务、调工具、读文件、改代码、再检查。循环里的每一步,都要把到目前为止积累的全部上下文,重新发给模型一次。 这就是 Agent 账单的根源。2026 年有人审计了 30 个在生产环境跑 Agent 的工程团队,一个 20 人的团队,单月 API 账单能冲到 11 万美元;用 Claude Code 或 Cursor 这类编码 Agent 的开发者,人均每月 400 到 1500 美元,失控的案例几天就烧掉 4000 美元以上。 更要命的是,这笔钱不是匀速烧的。Demo 跑得好好的,一上量就爆——大部分企业的 Agent 项目,在大规模铺开后的头 90 天里,实际花销会超出试点预算 4 到 11 倍。所以做 Agent,成本不是上线之后再优化的事,是设计时就得算进去的一笔账。 这篇把这笔账拆开:钱花在哪、怎么找到大头、有哪些真能省的手段、怎么设预算和熔断、怎么监控。 钱到底花在哪 先建立一个最反直觉的认知:Agent 跑一个任务的成本,主要不是输出,是输入。 模型 API 按 token 收费,输入和输出分开计价。聊天场景里,大家盯着输出看。但 Agent 不一样,它的成本大头在输入侧的重复计费。 为什么?因为对话历史会"滚雪球"。Agent 每调一次工具,就要把整段对话历史连同工具返回的结果,一起再发一次。一段已经积累到 10 万 token 的上下文,在后续每一次调用里,都按 10 万输入 token 收费——不是只收新增的那部分。一个跑到第 20 步的编码 Agent,光是文件读取塞进来的内容,单步输入就能超过 5 万 token,按 Sonnet 4.6 的价(每百万输入 token 3 美元)算,每一步 0.15 美元,二十步就是 3 美元,而这还只是一个任务。 ...

你试用一个 ASR 模型,拿手机对着它念一段稿子,转写结果几乎一字不差,你心里想:这事成了。 然后你把它接进真实业务。客户在马路边打来电话,背景是车流声;他说到你公司的产品名,转写出来是三个完全不相干的字;他报了一串订单号"一三幺零",屏幕上是"一三妖灵"。Demo 里的惊艳,到这里一点都不剩。 问题不在模型菜。开源的 Whisper、各家的流式 ASR,安静环境下的中文字错率早就压到了 3% 以下,这已经接近人工转写的水平。坑全在"安静环境、念稿子"这八个字之外——真实的语音是脏的,而工程的活,就是处理这些脏东西。这篇把落地之后才会碰到的坑,一个一个拆开。 第一个岔路口:流式还是非流式 这是接 ASR 之前必须想清楚的第一件事,选错了后面全是返工。 非流式(批量):把一整段音频丢进去,等它整段识别完,返回结果。流式:音频一边录一边送,模型一边听一边吐字,你能拿到不断更新的"中间结果"。 差别不只是"快一点慢一点"。它们是两类不同的产品形态: 维度 流式 ASR 非流式 ASR 典型延迟 首字 200–300ms,说完即出 等说完后再算,3 秒话约多等 0.5–2 秒 准确率 略低(只能看到左边的上下文) 略高(能看到整句,甚至整段) 成本 贵(常见 $0.016/分钟级别) 便宜(常见 $0.008/分钟级别) 适用 语音 Agent、实时字幕、点单 会议录音转写、客服质检、播客字幕 记住一个核心事实:流式之所以准确率低,是因为它在"说完之前"就得交答案。它做"我想订一张去——“的转写时,根本不知道后面是"北京"还是"报告”。非流式没这个包袱,它能等整句听完再回头修正,所以同样的模型,非流式版本的字错率往往低一两个百分点。 这里有个 2026 年很常见、但容易踩反的折中:用 VAD 把长音频切成"准句子",每段当成一个 mini-batch 走非流式模型。这套做法在"实时字幕"这种场景里很香——它不需要逐字滚动,用户能接受"一句一句往外蹦",于是你既拿到了非流式的准确率,延迟又只是一句话的长度。但如果你做的是语音 Agent,用户在等 AI 回话,那这套就不行——你必须真流式,让 ASR 和用户说话并行跑,说完文字基本也就好了。 别被"我两个都要"骗了。 一个产品里通常只有一条主链路。先确定用户是不是在"等",再选。 专有名词、中英混读、数字:错得最离谱的三类 通用 ASR 在通用语料上训练,所以它对"通用的话"很强,对"你的话"很弱。落地后用户投诉最集中的,永远是这三类。 专有名词。 你公司叫"声析",模型从没见过这两个字的组合,它会按发音找一个最像的常见词——“声息"“生气"“省吃”。这不是模型蠢,是它在做概率上最合理的猜测。人名、产品名、内部黑话、行业术语,全是重灾区。 中英混读。 中文工程师说话天然混英文:“这个 bug 我提了个 PR"“把 latency 压下来”。问题是很多 ASR 在"语种判定"上是僵的——它先猜你这句是中文还是英文,再用对应的解码路径。猜错了,“PR"变成"批 R”,“latency"变成一串看不懂的拼音。2026 年好一些的方案(比如 Gladia、Deepgram Nova-3)做了句内 code-switching,语种切换不需要整句重判;但便宜的、老的模型,中英混读仍然是硬伤。 ...

先说一个数字:Guardrails AI 在 2025 年初做过一次基准测试,结论里有句话很刺眼——单个护栏哪怕准确率有 90%,串五个,误杀率就到 40%。 这句话基本能概括做护栏的全部难处。你不是在"加保护",你是在一条已经够慢、够贵、够不确定的链路上,再叠一层会拖慢、会误判、还得自己维护的东西。问题不是"要不要护栏"——上线的 LLM 应用一定要有——问题是护栏管什么、做多厚、放哪一层。这三件事做错,护栏要么形同虚设,要么把好用户也一起赶跑了。 这篇不讲注入攻击的具体手法(那是另一篇的事),讲更宽的一件事:把用户的输入、模型的输出当成两道关口,这两道关口该怎么修。 护栏到底在拦什么 很多团队上来就装个 moderation API,以为护栏就是"过滤脏话"。不是。护栏分两侧,两侧拦的东西完全不一样。 输入侧,拦的是用户递进来的东西: 敏感信息。用户在对话里贴了身份证号、银行卡、内部工号、客户手机号。你不想把这些原样喂给第三方模型 API,更不想它们出现在日志里。 越界请求。一个做企业财报问答的 Bot,用户问"帮我写一首失恋的诗"。这不危险,但它不是这个产品该干的事——回答了,就是在替竞品做免费体验。 明显的恶意输入。攻击意图、自动化刷量、超长 prompt 灌爆上下文。 输出侧,拦的是模型吐出来的东西,这一侧更难,因为输出是模型生成的、不可预测的: 有害内容。暴力、仇恨、自残、违法信息。这是最经典的一类,也是 moderation API 唯一管得好的一类。 幻觉。模型一本正经地编了一个不存在的退款政策、一个错误的药品剂量。在 RAG 场景里,这意味着输出和检索到的资料对不上。 格式错误。你要的是一段能直接 JSON.parse 的结构化数据,模型给你前面加了句"好的,这是您要的结果:"。下游程序当场崩。 品牌口径。模型说了"我们的竞品确实更便宜",或者用了一个法务明令禁止的承诺词(“保证收益"“绝对安全”)。没毒,但能上财经新闻。 注意最后两类——格式和品牌口径——很多人根本不把它当护栏。但它们恰恰是上线后最高频出事的地方。有害内容一年可能出一次,格式错误一天能出一百次。 四种做法,从便宜到贵 护栏不是一种技术,是一个工具箱。按"成本/能力"从低到高,有四档。 第一档:规则与正则。 关键词黑名单、正则匹配身份证/手机号、长度限制、JSON schema 校验。便宜到几乎不要钱,延迟个位数毫秒,而且结果可解释——你能准确说出"它是因为命中了第几条规则被拦的”。缺点也明显:绕得过,且管不了语义。规则适合拦"形状固定"的东西:PII、超长输入、明确的禁用词。 第二档:专门的分类模型。 这是 2026 年的主力。Meta 的 Llama Guard 是一个专门微调出来的输入输出安全模型,自带六大类不安全分类,还能自定义类目;OpenAI 的 omni-moderation-latest 免费、能同时分类文本和图像。它们的关键优势是快——一个专用 guard 模型跑一次大约 29 毫秒,而拿一个大模型当审查员要 5 到 11 秒。但要清楚它们的边界:OpenAI moderation 只做内容分类,不查注入、不查幻觉、不做 PII 脱敏。它是基线,不是全部。 第三档:用 LLM 审查 LLM。 让另一个模型(或同一个模型换个 prompt)去判断"这条输出有没有问题"。最灵活,能处理"品牌口径"“答非所问"这种规则和分类器都搞不定的模糊判断。代价是它慢且贵——等于每个请求多一次完整的 LLM 调用,延迟翻倍,成本也翻倍。LLM 审查适合留给"少量、高风险、规则写不出来"的判断。 ...