今日概览
今日六篇集中在 Agent 落地的三层工程问题：底座层是 AI Infra 与推理工程（腾讯老兵转行的路径与推理工程知识地图）、协作层是 Agent 与团队共用文件空间（火山引擎 ADrive）、执行层是工程验证（得物登录系统改造的验证链路）与决策降本（Jev 决策模型两篇）。另有一篇把 Agent 工作原理（Harness 如何编排上下文）讲得很通俗。
今日重点
1. 腾讯15年资深后台工程师，转战大模型推理的抉择
腾讯 T12 搜索后台老兵 2025 年初主动卸掉管理头衔，以"零级新人"身份转投大模型推理工程。文章是三段自省：为何在将至不惑之年选择归零、推理工程如何入门与自检、AI Infra 与通用 Infra 的同源与分野。
值得关注：
- 两条切入路径：一是他这种归零重来，二是从通用 Infra 逐步做"AI 化改造"渗透进 AI Infra——不必先从 GPU 加速入手，平台化建设、研效提升与稳定性保障同样是 AI Infra 的组成部分。
- 推理工程的核心矛盾是算力、显存、通信三者的权衡：Prefill 计算密集、Decode 显存带宽密集；KV Cache、Continuous Batch、Prefix Cache、TP 等技术本质都是在硬件约束下以最低成本换吞吐、降时延。
- 入门建议"先总后分"：先对 Transformer 结构建立体系认知（Embedding、Attention、FFN、Normalize、Residual、LM Head），再逐个击破。
- 判断：Agent 模式以多轮交互、长耗时、有状态、长生命周期为核心特征，带来长会话调度、状态持久化、长短记忆管理、工具沙箱隔离、Agent 可观测与评估等新 Infra 问题，正是传统分布式与系统工程经验能发挥作用的地方。
来源：腾讯技术工程
2. Agent 已经进入工作流，文件还要靠人传来传去？
火山引擎 ADrive 智能网盘要解决的是：报告分析可以交给 AI，但围绕这份报告的资料上传、结果下载、转交同事、同事补充数据后重新交给 Agent，一整套文件交接仍靠人工。
值得关注：
- 统一空间：原始资料、分析草稿和最终报告都放在 ADrive 同一项目空间，团队在此整理审阅，Agent 在此读取与保存成果。
- 本地挂载：项目空间可挂载为本地盘符，团队成员用桌面应用编辑，接入的 Agent 在项目文件夹中读写——同一文件夹连接 AI 处理与同事的后续工作。
- 权限与追溯：文件交给 Agent 时权限规则仍生效，读取哪些资料、写入哪些位置由身份与权限配置决定，操作留审计记录。演示中三次未授权的写入尝试均被拒绝。
- 成果协作：在线预览、历史版本恢复、外链分享（有效期、密码、下载权限），从审阅到修改再到交付同一份文件贯穿全程。
来源：火山引擎
3. 一个字都不会写的 Jev，凭什么成为 ChatGPT 之后最火的模型？
TypeSafe AI 的 Jev 完全不生成文本，却能把很多 AI 决策成本大幅降下来。它被官方称为"系统一（System One）模型"：输入一段非结构化数据，直接输出强类型的选项和精准的置信概率。
值得关注：
- 核心逻辑：当代码已经知道全部可能出现的答案时，逐字文本生成就是巨大浪费。Jev 不做长文生成，只做高频确定性判断。
- 三个成熟落地场景：模型路由（按任务难度分派廉价/昂贵模型）、工具执行风控（调用终端命令前判断只读/可逆/破坏性，破坏性操作暂停待授权）、结果校验与监管（测试是否跑通、是否陷入重复调用死循环、输出是否违背规则）。
- 边界要说清：类型安全保证的是输出结构不崩溃，不保证业务判断不出错——“一个符合类型定义的错误判断，依然可能错误地退款、错误地分发故障工单”。
- 接入方法论：挑一个维护成本最高/易错的正则，或一个"只为拿到是非判断"而调用大模型的节点 → 明确写出该节点所有可能的选项定义 → 开 Shadow 影子模式与现有逻辑并行跑、校准置信度阈值 → 准确率达标后再正式切流量。
- 定位是配合而非取代大模型：大模型写代码、写方案、做长文本推理与沟通；Jev 围绕它做高频快速的边界控制。
来源：数字生命卡兹克
4. 边开飞机边换引擎：Harness如何解决验证难题
两个月内完成一套大型登录系统替换、同时正常需求开发不停，作者发现真正的阻塞不是"让 AI 多写点代码"，而是验证——公共环境不能随意停 Redis、断 DB，预发环境一次变更从发起到可验证要 30 分钟至 1 小时。
值得关注：
- 核心原则：不让 AI 当"自由执行命令的操作员"，而是把高频、关键、易错的操作固化为受约束的工作流——给 AI 一个可复用、可审查、边界清晰的操作入口，而不是每次从零生成一串命令。
- 第一步用 Makefile 固化"代码到镜像"：统一 Dockerfile、构建上下文、镜像 Tag（含多架构），推送 CSGHub，输出可部署的镜像地址；AI 在明确约束下调用 Makefile，失败时辅助分析日志。
- 第二步用小 TKE 降低 K8s 门槛：前端页面管镜像、Workload、Helm Chart、ConfigMap 与多集群；平台本身只提供统一入口，真正的 Workload/Pod/依赖仍部署在各开发者 DevCloud 机器、保持隔离。
- 一条重要经验：Skill 适合承载已收敛、边界明确的标准动作，但不要把复杂性全暴露给使用者——高频确定的部署验证操作，简单直观的工具界面往往比模糊 Skill + 多轮对话更可靠（新人曾用 AI 误建多个 Namespace、进错集群）。
- 项目维度的排障小工具：Token 重新签发（区分 Token 签发问题与接口鉴权问题）、Session 解密（定位登录态与会话续期）。单次验证准备从 30-60 分钟压到约 5 分钟。
来源：腾讯云开发者
5. 简单讲讲 Agent 的工作原理
以原理视角讲清楚 Agent 产品背后通用的一套机制：Harness 对上下文的自动化编排，让模型一步步把事情做完并输出结果。
值得关注：
- 模型的输出可先理解为两类：上下文够了就输出结果；不够或要执行动作就调用工具（function call）。
- 要分清三个范围：电脑里保存了什么、会话里发生过什么、模型此刻收到什么——只有第三类构成当前判断的依据。
- 循环：模型提出操作 → 工具执行 → 结果返回 → 进入下一次判断。工具既让模型采取行动，也让模型获得新的信息，这正是"生成了代码"与"完成了任务"之间距离被拉齐的原因。
- Skill 渐进加载：先提供名称、简述和位置，模型判断需要哪一项再读详细说明，避免用不到的说明挤占本可留给任务材料的空间。
- 历史压缩与文件重读：工具返回可先限制体积（截断或落盘只给预览），历史过长再按策略整理压缩；界面上能翻到的旧记录，未必仍完整出现在当前请求中，需要细节时通过工具重新读取。
- 多 Agent 交接要同时安排两件事：谁做哪部分、做完交回什么。结果压得过短会丢掉关键依据，结构化交接校验只能解决其中一部分，来源是否可靠仍需核对。
来源：腾讯云开发者
6. 聊聊最近爆火的Jev 模型，到底是个啥？
腾讯程序员亲手做了一个网页小游戏 demo，用来搞清楚一个更值得讨论的问题：搭 Agent 时经常让通用大模型反复决定下一步，这里面有多少事情真的需要完整的生成与推理能力？
值得关注：
- 三种接口：Choice（在预定义选项里选一个，返回各选项概率与 confidence）、Score（按定义等级评分）、Noul（是非判断，返回 0—1 的概率）。
- 本质是分类模型。在 Browser Use 的航班查询例中，一次查询 7.073 秒里用了 17 次 Jev 请求、仅 2 次文字生成调用——“选下一步"的次数明显多于"写文字"的次数。
- 一个容易混淆的细节：confidence 是从答案概率分布算出的统计量，不是"这次一定有多大概率正确”，也不是通关概率；要拿它决定是否自动执行，得先用自己的数据检验概率校准。
- 三点可能收益：更适合反复调用的线上场景（官方公布响应约 70—500ms、输入每百万 tokens 0.042 美元）；减少没必要的串行步骤（一次同时判断业务类别、紧急程度、信息是否齐全）；让程序有机会识别"犹豫"（明显偏向 A 与 A、B 接近，后续处理可以不同）。
- 定位与边界：夹在规则/专用小模型与通用大模型之间——任务需要通用语义理解、规则与候选频繁变化、又不想为每个小判断单独训模型时最合适。长期看，迁移成本与服务质量比"单次推理便宜"更关键。
来源：腾讯程序员
趋势观察
- Agent 的瓶颈正从"模型能力"转向"工程链路" — 今天三篇不同来源的实践分别落在底座（推理工程与长会话状态）、协作（Agent 与团队共用文件空间）、验证（隔离环境与可审计操作）三层，重点都不是"模型能不能做"，而是"系统能不能稳定落地"。
- 决策与生成开始分层 — Jev 这类 System One 模型把高频小判断从通用大模型里剥离，用强类型输出与置信度换延迟和成本；大模型负责生成，小模型负责边界控制，二者是配合而非替代关系。
- “给概率性输出套结构约束"成为共识 — ADrive 的未授权写入被拒、登录系统的受约束 Skill 与固化 Makefile、Harness 的固定工作流，本质都是同一件事：用结构化的边界和门禁，约束模型的自由发挥。