如果你手头正在做 Agent 相关的工作最近这几个信号值得停下来看一眼某个主力编码代理产品预告了 Work 模式的“连续二十八天功能改进”一家大厂放出了开放权重的视觉语言模型安全社区则在集中讨论恶意 Skills 对 Agent 的威胁。三条消息来源完全不同但拼在一起几乎就是智能体开发当前阶段的浓缩版——能力正在快速产品化、模型权重开始向本地化下探、安全风险的重心从模型本身转移到了工具链和技能层。我在过去两个月里同时推进了几个模拟项目一个基于编码代理的自动代码审查流水线一个面向本地文档审阅的视觉 Agent以及一组给 Agent 做工具权限隔离的防护实验。三件新闻刚好都命中了我正在做的事所以这篇博客不是打算做新闻转述而是想以一线开发者的视角把这三条信息背后的判断框架和实操方法拆给你看。接下来按顺序展开。1. 先说 Codex / Work“连续 28 天改进”背后值得关注的不是日历1.1 连续改进是一种产品策略也是一种开发信号“连续 28 天改进”这类预告本质上是一种持续交付的节奏展示。如果只看表面很容易得出“厂商又在制造话题”的结论但放在编码代理这个品类里这种节奏本身就有信息量说明核心工程团队已经把开发流程切换到了“小步快跑、每日可发布”的状态而不是传统的季度大版本。我接手过几个自动化工具的迭代项目深知“连续发布”对内部工程的要求有多高。本质上它要求三条链路同时在线第一功能开关要足够成熟新能力默认关闭只有少数白名单用户能提前体验第二CI 要快从代码提交到可测试产物需要在小时级完成第三线上监控要把“功能使用率”和“用户反馈”回传闭环。能做到这一点的团队说明他们对代码质量、测试覆盖和灰度发布有相当信心。放回 Agent 这个场景连续改进的意义更大。Agent 不同于普通软件它在非确定性环境里运行每次运行的结果都可能与上下文相关。如果一个 Agent 产品一个月才发布一次新版你根本分辨不清一次行为变化是“模型抽风”还是“版本升级导致”。反过来高频迭代让新行为快速出现也让问题更早暴露。对使用者而言你需要做的反而是建立自己的回归基线不然很容易被版本更新带偏。我在实测某个编码代理的 Work 模式时常见做法是每周重新跑一遍固定的任务集包括提单、改代码、跑测试、提交 PR、处理 review 意见。任务集不追求复杂关键是固定。只有固定才能看出版本变化带来的行为漂移。1.2 Work 模式到底解决了什么问题编码代理的“Work”后台工作模式可以理解为把 Agent 从“对话里写代码”升级为“给它一个目标它自己安排步骤去完成”。听起来简单实际差别很大。对话模式更像结对编程开发者提需求、看结果、纠正偏差。Work 模式则更像是把任务交给一个远程协作者它会自己读取仓库、创建分支、试探性修改、跑测试最后把改动提交并附上说明。对你的工作流来说等于把一个可以并行的执行者放进了开发流程。它能干活但你得给它清晰的边界。我在实践中发现Work 模式最有效的场景是有明确验收标准的机械性重构。比如把某个内部库里的全部 logger 切换为结构化日志格式或者批量把某个 API 替换成新版本。这类工作规则简单、后果可验证Agent 非常适合。反过来如果任务本身是模糊的开放性问题比如“优化系统性能”它往往会把一堆无关模块都改一遍Review 成本会非常高。这也是连续改进最值得期待的地方一个做得好的 Work 模式应当知道何时停下来问人而不是铆足劲把无关代码也改掉。你可以通过它对“不确定性任务”的处理方式来判断这个产品进步了多少。1.3 给跟着节奏走的团队三点建议第一别追每个新版本按周或按双周集中验证。高频发布下逐天跟进反而容易疲劳还会把偶发问题当回归。我把验证节奏设为每周三避开发布刚生效的头两天。第二建立自己的任务回归集内容要考虑“行为可判断”。比如规定“必须更新测试”“必须给出变更摘要”“遇到模糊需求应提问”这些行为比“输出代码质量”更容易稳定评估。第三注意观察默认权限。新版如果出现新的自动执行能力默认开启还是默认关闭直接决定你的流程风险。我习惯在升级后立刻查一遍配置项把涉及写文件、发网络请求、合并分支的能力全数检查一遍。2. 再说开放权重模型Kolibri 带来的本地化变量2.1 Kolibri 的位置小参数、强视觉、可私有部署Kolibri 这条消息如果把厂商和营销包装都剥掉核心事实是又一款开放权重的视觉语言模型进入了本地部署候选池。它给我的第一印象是“参数规模不大但对视觉理解做了针对性优化”。这类模型通常会被用来处理截图理解、表格识别、文档版面分析等视觉任务正好是不少 Agent 产品缺的那块拼图。我在做某个面向内部资料审阅的视觉 Agent 时深刻体会过“通用多模态模型不够用”的尴尬。通用模型确实能看图但面对密集的表格、复杂的表单布局输出容易缺行漏列。开放权重模型则允许你在自己的数据集上做后训练把版面理解能力打磨成适配特定业务的形式。对数据敏感的场景来说权重开放意味着整个推理过程可以完全离线这本身就有巨大的合规价值。还要说明的是开放权重不等于开源软件。虽然你拿到了权重可以部署、微调但使用条款、衍生发布规则仍然要看具体授权协议。商用前先把 license 看明白是我给所有团队的第一条忠告。2.2 开放权重给开发者的三个真实价值第一个价值是可审计。闭源模型的推理过程是个黑盒出了问题你只能猜。开放权重模型允许你做本地推理、复现实验、记录一份完整的输入输出日志遇到问题能把整个链路交给安全团队审查。第二个价值是可控微调。你完全可以拿几百条业务样本做一次轻量微调让模型更懂你的领域术语。相比从零训练适配成本低到可以忽略。第三个价值是成本可预测。闭源 API 的计费模式随着规格不同变化很大长上下文和高频图片输入会迅速累积成本。本地推理的成本主要是硬件折旧和电费对高频、大批量的场景更加可控。我在评估模型时并不只看跑分更看重它在真实场景中的“失败模式”。曾经同时测过几款视觉模型在标准评测集上差距很小但一旦把输入换成带彩色标注的工程图纸有的模型频繁漏掉颜色标记有的模型则稳定输出。开放权重模型的好处是你能自己造出这种偏科样本低成本地把模型短板测出来。2.3 落地时需要面对的现实问题开放权重不是万灵药。推理要占 GPU 资源大并发仍然需要工程优化。我的建议是优先考虑量化版本显存有限的情况下4-bit 量化在视觉任务上的质量损失通常可控但吞吐会有明显提升。另外模型在 Agent 链路里往往只是其中一个组件。真正要跑通的是“视觉理解结果到结构化指令”的转换。我踩过的坑是模型输出的 JSON 格式不稳定偶尔会多一个引号或嵌套层级错误直接把下游工具调用打挂。后来加了 schema 校验和自动修复层问题才基本解决。这类工程细节光看评测报告完全看不出。我个人判断Kolibri 这类开放权重模型对 Agent 领域的真正意义不是“哪个跑分刷新”而是让视觉 Agent 的闭环第一次可以完全跑在本地。对内部数据敏感、有离线部署需求、想要深度定制视觉能力的团队这是一个值得认真评估的新选项。3. 恶意 SkillsAgent 安全的重心正在从模型层转移到工具层3.1 Skills 机制为什么是天然的攻击面所谓 Skills技能是 Agent 系统里用来扩展能力的模块一段指令、一个脚本、几个工具封装都可以打包成 Skill。它的设计思路是“把某个专项能力做成可复用插件”让 Agent 在需要时加载。这是非常自然的软件工程演化但也带来一个安全结构问题Skill 本质上是一份「由第三方提供的、将要被 Agent 自动执行的代码或指令」。如果某个 Skill 来自不可信来源里面藏了恶意指令Agent 在加载并执行该技能时就可能被诱导做出越权行为。很多团队的 Agent 给模型层的安全很足有系统提示词防注入、输出过滤、内容审核但 Skill 的执行往往绕过了这些控制。原因是 Skill 通常直接对接工具调用一旦它被模型信任并激活就会以一个合法权限执行操作。这个问题的根源可以类比为一个很熟悉的场景你的电脑上装了一个“看起来人畜无害”的浏览器插件但它实际上在后台读取你的浏览记录。Agent 的 Skills 生态如果不提前防护就会重演浏览器插件时代的供应链安全危机。3.2 恶意 Skill 的常见攻击链结合安全社区最近集中讨论的案例我把恶意 Skill 的攻击链拆成四段第一段伪装。攻击者发布一个表面功能正常、实际包含隐藏指令的 Skill。名称往往使用“效率提升”“文档处理”“网络诊断”这类通用词汇因为这类技能容易被高频加载。第二段激活。开发者在不知情的情况下安装了这个 Skill或者用户在一次对话里被诱导说“启用某个技能”Skill 随之被加载。这里的关键是模型对 Skill 的信任度往往高于对用户输入的信任度所以 Skill 内部的指令更容易被当作“系统级指令”执行。第三段执行。恶意 Skill 在运行时向 Agent 注入被隐藏的提示词要求它读取本地文件、截图、扫描目录、连接第三方服务等。由于 Skill 是合法模块这些行为往往会绕过安全策略。第四段外传。Skill 把读取到的数据发送到一个外部地址或者把 Agent 的执行结果篡改成攻击者想要的样子。对编码类 Agent 而言最危险的后果是修改代码逻辑、注入后门、篡改依赖。攻击未必立刻被发现很可能在后续的版本迭代中才浮出水面。我建议每个做 Agent 的团队都做个实验用一个内部测试账号故意加载一个模拟恶意 Skill观察它是否能顺利读取一个标记好的敏感文件并把它拼接进日志。实验结果通常会让你背脊发凉因为它往往真的能。3.3 工程侧可以落地的防护清单安全意识落地要靠具体的机制设计。我现在的防护思路可以概括为四层第一层来源可信度评估。对每个 Skill 做来源评级默认不信任生态里的陌生技能。公司内部开发的技能和经过安全审计的第三方技能才能进入白名单。第二层最小权限授权。Skill 的运行权限要单独配置而不是共享 Agent 的主权限。比如文档处理类的 Skill 就不应该拥有网络请求权限图片分析类的 Skill 也不应该能读取代码目录。权限设计遵循“按需分配、运行即回收”。第三层运行时沙箱隔离。给 Skill 提供独立的执行环境限制文件系统、网络、进程访问范围。至少要保证一个恶意 Skill 无法直接读取 Agent 系统目录和密钥文件。第四层行为审计与异常检测。记录 Skill 的所有执行日志包括读取了哪些文件、调用了哪些工具、向外发送了什么内容。一旦发现异常行为模式比如深夜频繁外发数据就应触发告警并回收权限。提示在 Agent 产品里提示词注入是“模型层”的问题恶意 Skill 是“供应链层”的问题。大多数团队对前者有防护对后者几乎是裸奔。如果只做一件事先把公司内部的 Skill 白名单机制建起来。4. 把三条信息串起来Agent 项目当前的三个关键动作4.1 建立 Agent 迭代的“回归基线”连续改进的编码代理和不断出现的开放权重模型会让 Agent 项目进入一个高频变化期。这时候如果没有可靠回归基线很容易被版本节奏带着走。回归基线不必复杂。我建议它至少包含固定任务集、固定评估维度、固定安全测试。固定任务集解决“今天能力是否有提升”的问题固定评估维度解决“变好还是变坏”的问题固定安全测试解决“会不会引入新的越权风险”的问题。把这三个固定做扎实比追逐任何一个新功能重要。4.2 先把本地模型引入“副驾驶位”Kolibri 这类开放权重模型的到来意味着我们可以把小模型放进 Agent 架构里作为预处理器或旁路判断器。我的做法是让本地小模型先承担结果校验角色当主模型决定调用某个工具时小模型先对参数做一遍合法性检查主模型输出中包含敏感信息时小模型负责拦截。这种“副驾驶位”的好处是没有改变主链路却能显著降低安全风险。如果团队有精力做更深度的集成可以考虑把视觉模型嵌入“界面理解 Agent”的链路。对需要操控 GUI、读取截图的 Agent本地视觉模型能减少把截图直接发送给闭源 API 的合规压力。4.3 把 Skills 当作“代码依赖”一样管理最后也是最重要的一点把 Skills 当作一个有完整软件供应链的管理对象。具体来说要有统一目录和版本号而不是散落在聊天记录和文档里。要引入签名和哈希校验确保加载的 Skill 就是你要加载的那个版本。定时做安全扫描把 Skill 内的提示词、脚本代码、网络请求全部纳入扫描范围。给每一次 Skill 使用记录加上 trace id出了事能回溯到具体某次调用。建立“不可信 Skill”隔离区所有来源不明的技能先在里面运行观察观察期通过后再转正。我在内部推动这套机制时最大的阻力不是技术而是习惯。开发和产品同事总觉得“先跑起来再说”但 Agent 涉及代码生成和自动执行一旦被恶意 Skill 注入损失远大于前期那点效率。5. 实际测试记录与避坑清单5.1 我最常遇到的三类问题第一类模型对 Skill 指令的信任度太高。我故意把一条“忽略之前的安全约束”写进一个 Skill 的说明里结果主模型确实触发了越权操作。这个实验让我意识到人写的安全提示词在技能指令面前很容易失效需要做工程强制而不是靠提示词劝告。第二类本地视觉模型输出的结构化数据不稳定。开放权重模型在截图 OCR 之后经常输出残缺的 JSON 字段。我花了三个晚上写补全逻辑最后得出的经验是宁可要模型输出纯文本也不要放它自由生成 JSON。纯文本之后由代码解析稳定性会高很多。第三类权限配置容易被绕过。某个模拟项目里我一开始把 Agent 的文件读权限只开放给工作目录但一个 Skill 通过创建符号链接的方式指向了目录外文件。这个教训告诉我沙箱隔离不能只看“目录权限”还要看系统调用级别的能力。5.2 给 Agent 开发者的最小自查表每次迭代发布前我会用这张自查表过一遍[ ] 所有外部加载的 Skill 是否有来源记录和哈希校验[ ] 是否有 Skill 或工具可以访问超出任务范围的目录、文件、环境变量[ ] 是否有工具具备网络发送能力如果有发送是否经过白名单地址校验[ ] Agent 在收到“忽略之前指令”等冲突指令时是否会触发人工审核[ ] 本地模型的输出是否有 schema 校验和自动修复[ ] 核心执行链路是否有完整的 trace 日志方便回溯和审计如果答案里有任何一个“否”我都不会把系统放到生产环境。写到这里三条看似不相关的新闻其实已经被一条线索打通Agent 正在从“模型能力演示”走向“工程化落地”。连续改进说明产品迭代要跟上快速变化的模型能力开放权重模型说明本地化部署的性价比已经进入可接受区间恶意 Skills 则提醒我们真正的瓶颈往往不是模型不够强而是我们对 Agent 执行链路的信任模型还停留在上个时代。我在实际操作中的体会是这个阶段做 Agent拼的早就不只是谁的模型更强而是谁的错误恢复机制更稳、谁的权限边界更清晰、谁的供应链可以被审计。把这三点做实无论是跟随连续改进的编码代理、接入开放权重模型还是抵御恶意 Skill都只是时间问题。