这周AI圈子里几条消息凑在一起，信息量其实不小。一边是Codex / Work放话要搞28天连续改进，一边是Kolibri把开放权重的大模型摆上了台面，同时又有恶意Skills攻击Agent的案例被扒出来。这三件事单看各是各的，但放在一起，明显能感觉到Agent开发这条赛道的风向变了：工具的迭代速度在加快，本地化部署的自主权在变大，而安全问题的复杂度也在同步上升。作为一个实际把Agent工作流接到日常开发里的从业者，我对这三条消息的关注点可能跟纯技术新闻不太一样。我更关心的是，Codex / Work这波连续更新到底会用到哪些能力上，Kolibri的开放权重能不能真正降低我们团队的部署成本，以及那个恶意Skills攻击，我们的项目是不是也暴露在同样的风险里。这篇文章就围绕这三个话题展开，结合我自己实践中的一些观察和踩坑经历，聊聊我眼中的趋势和应对思路。1. Codex / Work 28天连续改进，到底在挤什么牙膏先说说Codex / Work这个预告。28天连续改进，一天不落，这个节奏在AI编程工具里确实不算常见。大多数产品都是按里程碑发版，来个2.0、3.0的大版本更新，然后配套写一堆release notes。像这种"连续改进"的承诺，更像是移动互联网时代App那种"周更"甚至"日更"的玩法，把迭代周期压缩到极致，用高频反馈来修正方向。1.1 为什么是"连续改进"而不是"憋大招"我个人的理解是，AI编程助手这个品类跟传统IDE插件有本质区别。传统插件的能力边界是确定的，你定义好功能，做出来，发布，完事。但基于大模型的工具，能力的提升很大程度上取决于模型本身的推理能力、上下文理解能力和对代码库的感知能力，这些能力是可以通过持续调优不断往上走的。既然模型每天都在进步，那产品层面的迭代就不该被发版节奏捆住手脚。从用户的角度看，"28天连续改进"更像是一个姿态声明：团队把自己放在了一个必须持续交付的位置上。这种做法对内部团队的要求极高，意味着每一天都要有东西可交付，倒逼研发管线高效运转。对我这种每天在用工具干活的开发者来说，最直接的好处是反馈回路变短了。今天提交一个bug，可能过两天就修掉了，而不是等上两三个月。另外一个值得注意的点是，Codex / Work背后的思路可能不只是修bug，而是让工具在复杂任务上的表现持续变好。比如处理多文件改动时的上下文连贯性，比如长任务的执行稳定性，再比如对用户代码风格的学习能力。这些能力靠一次大版本更新很难做到位，必须靠持续的小步快跑打磨。1.2 从迭代方向反推产品重点虽然没有详细的路线图，但从AI编程助手的普遍痛点上，大概能猜到28天里重点会动哪些地方。第一是上下文管理的优化。用过AI编程助手的人都有体会，对话一长，它就容易"忘事"。尤其是跨文件重构这种场景，前面改了一个模块的接口，后面让它改调用方的时候，它可能就忘记了前面的约定，导致代码风格不一致。改进的方向大概率会集中在结构化上下文上，让工具能更有效地在长对话中保持对关键信息（比如接口签名、变量名、模块结构）的记忆。第二是工具调用链路的稳定性。Agent类编程工具的核心能力之一就是自主操作终端、编辑器、代码搜索等工具。这个链条上任何一个环节出错（比如命令执行超时、文件路径解析错误、权限不足），都会中断整条任务。连续改进的重点应该是在错误发生后如何优雅地恢复，而不是直接放弃。第三是安全边界。这一点很关键，配合后面要聊的恶意Skills话题，AI编程工具体系里涉及外部代码和插件执行的场景，权限控制必须更精细。比如从云端市场安装一个Skills包，它到底能访问本地文件系统哪些目录、能不能执行shell命令、能不能读取环境变量里的密钥，这些都是需要明确区分和管控的。1.3 开发工作流会被怎么影响如果Codex / Work这波连续改进能兑现，对开发工作流的直接影响有两个。一个是AI辅助编码从"单点辅助"走向"全流程代理"。以前是让AI写个函数、补个测试、解释一段代码，人始终把控着节奏。现在是直接把整个任务丢给Agent，让它自己规划步骤、自己查资料、自己改代码、自己跑测试。这个转变不只是效率提升，而是开发模式的改变，人从每一个细节的执行者，变成了最终结果的审查者。这也是为什么Codex / Work这类工具把"Work"放在名字里，它要处理的不是孤立的代码片段，而是一整条工作流。另一个影响体现在团队协作层面。当AI能更可靠地处理重复性开发任务时，团队中更初级的工作（比如写模板代码、修简单bug、整理测试用例）会逐渐被Agent消化。这会让团队花在代码审查上的比重增加。我见过不少团队已经建立了"AI提PR、人来审查"的流程，这个模式在改进后会更加普及。注意：这类工具的连续更新有个隐形风险——你昨天验证好用的工作流，今天可能因为某个微调就变了。建议不要把Agent当黑盒来依赖，关键的行为变更要跟进changelog，自己的工作流也要定期复盘是否还适配。2. Kolibri开放权重，本地化部署的下一个可选答案聊完工具侧，再看另一个消息：Kolibri开放权重。开放权重这四个字对搞过本地部署的人来说，含金量还是高的。它意味着你可以把这个模型下载到自己的机器上跑，可以做微调，做量化压缩，甚至做一些内部的二次开发。相比只能通过API调用的封闭模型，开放权重给团队保留了极高的自由度。2.1 开放权重和开放源代码不是一回事先说个容易被混淆的概念。开放权重（Open Weights）并不等于开放源代码，你拿到的是训练好的神经网络参数文件，而不是从头训练这个模型所需的数据集和训练代码。这种模式的定位很清晰：官方把模型训练好了，参数给你，你可以拿去部署、微调、商用，但你不能从零复现整个训练过程。这个区别决定了Kolibri的适用场景。它不是用来做学术研究、探索新架构的那种模型，而是用来直接落地到生产环境中的模型。想象一下，训练一个几B甚至几十B参数的模型需要成百上千张GPU卡跑几个月，绝大多数团队没有这个资源。但部署一个已经训练好的模型，一张消费级的GPU可能就够了。开放权重本质上是把"训练成本"和"推理成本"做了一个切分，让团队只需要承担推理侧的硬件成本。2.2 开放权重解决的实际问题在实际工作中，开放权重模型解决的问题往往体现在三个维度。数据隐私是最刚性的需求。我们之前做过一个内部知识库问答系统，数据涉及客户资料和内部策略，这些内容无论如何不能发送到外部API服务去处理。用开放权重模型做本地部署，数据完全不出内网，合规压力一下就小了很多。这里没有模棱两可的空间，数据出境合规是所有做企业服务的人都要过的门槛。如果你是做内部工具，开放权重几乎是唯一可行的模型路线。成本结构的变化也很实际。API调用费用是随着调用量线性增长的，每天几千次问答，长期看是一笔不小的开销。而部署本地模型是一次性硬件投入加电费成本，调用量越大，单位成本越可控。等到调用规模再上来，这个账算下来差别会很大。第三个维度是定制空间。基础模型通过API调用，能力边界基本被限定死了。而开放权重模型可以做微调，让它更贴合你所在领域的术语和表达习惯，这也是API模型很难替代的价值。2.3 部署实操的几个关键点基于我自己的部署经验，如果你要尝试Kolibri这类的开放权重模型做本地部署，有几点值得提前规划。硬件选型要先看模型参数量。几B参数的模型，消费级显卡就能跑，量化后内存占用可以控制在十几GB以内。几十B级别的模型，就需要考虑两张或更多显卡的方案，或者直接用大显存的服务器。量化格式的选择也很重要，以我常用的量化工具套件为例，4-bit量化在推理速度和质量之间是比较均衡的权衡点。官方原版权重的FP16格式准确度最高，但显存占用也大，生产环境更推荐用4-bit或8-bit的量化版本。推理框架需要根据场景选。如果做的是延迟敏感型的交互式应用，比如在线问答助手，选那种支持Continuous Batching、能并发处理多个请求的推理服务，这样可以用一个模型实例服务更多用户。如果做的是离线的批量数据处理，比如给一批文档生成摘要，那并行度和吞吐量优先，牺牲一些推理时延问题不大。另外，开放权重模型的原生能力往往集中在通用对话和代码理解上，要让它在你的垂直场景里表现好，建议先试几次few-shot提示词，看看能不能满足需求。如果尝试后发现效果还不够，再考虑微调。我自己遇到过的经验是，先做提示词工程，后做微调，成本能省不少，而且踩坑概率大大降低。实操提示：模型权重就像是发动机，推理框架是变速箱。权重本身决定性能上限，但推理框架决定你能否把这个上限有效发挥出来。两者需要搭配好，别只盯着权重文件，忽略服务框架的调优。3. 恶意Skills再敲Agent安全警钟第三个消息可能是最需要引起重视的：恶意Skills引发的Agent安全事件。相比编程工具的功能迭代和模型权重开放，安全问题的直接后果更严重，不是影响效率，而是直接威胁到代码资产、数据资产甚至整个服务器环境。3.1 Skills机制为什么会成为攻击面先解释一下Skills在Agent生态里扮演的角色。Skills可以理解为一个能力扩展包，Agent装上某个Skills之后，就学会了执行某类任务。比如安装了一个"代码审查Skills"，Agent就能输出结构化的代码审查意见；安装了一个"PDF解析Skills"，Agent就能读取和处理PDF文件。这个机制本身是好的，它让Agent的能力可以像App一样低门槛扩展。但问题在于，Skills的安装路径天然是开放的。你可以从市场下载，也可以从开源仓库拉取，还可以从个人博客粘贴一段配置。这跟手机上装App很像，区别在于，手机App的上架审核尚且有一套流程，而Agent Skills的分发目前基本没有严格的审核机制，可以说谁都能发，谁都能装。只要这个口子开着，攻击者就有机会在不接触你系统内部的情况下，只通过一个看似无害的Skills将恶意指令送进你的Agent工作流。这种攻击在AI生态里并不少见，它往往不声不响。系统没有被打出明显的洞，账号也没有异常登录，一切看起来正常得很。但数据已经在流向不该去的地方了。3.2 恶意Skills的攻击路径拆解我梳理了一下恶意Skills的典型攻击路径，大致可以分成三个阶段。第一阶段是伪装上线。攻击者会制作一个功能正常的Skills，让它真的能完成你需要的任务，比如确实能解析PDF、确实能生成周报，表面看完全没问题。甚至会在例子里放几个正经的正向输出，引导你在初步验证时认为它"可用"。只有在特定触发条件下，它的恶意逻辑才会被激活。第二阶段是潜伏执行。当Agent调用这个Skills处理真实任务时，恶意指令被触发。这个指令可能藏得极深，可能伪装成"参考文档格式"的提示词，实际上却在引导模型将聊天记录、代码片段、数据库连接信息打包发送到一个远程地址。大多数用户在Agent正常工作的时候不会去检查输出日志里有没有多余的网络请求。第三阶段是横向渗透。拿到初步数据之后，攻击者会尝试更高层级的操作。如果Agent的运行环境还配置了访问其它内部系统的权限（比如能连数据库、能访问密钥管理服务、能操作代码仓库推送分支），攻击者就能通过这些跳板进一步渗透整个系统。这比单独拿到一两份文档严重得多。3.3 攻击案例分析：一次被忽略的异常请求讲一个我实际经历过的案例，可以更直观地说明问题。某次做前端任务时，我从一个第三方仓库下载了一个号称"自动补充CSS样式前缀"的Skills。第一次测试时它表现正常，正确地给几条样式规则加了厂商前缀，我就放心地把它接进了工作流。当时留意到一条异常日志，Agent运行期间往一个不熟悉的域名发了一次POST请求，但我没有细想，以为是版本更新检查机制。后来排查一个网络问题时才发现，那个域名根本不是官方域名。这个Skills在任务执行的某个节点，会把工作目录下的文件列表、项目结构信息以及部分环境变量打包发送出去。幸好那次任务涉及的代码不敏感，否则后果会很难收拾。这件事给我一个教训，第三方Skills不能因为"看起来有用"就直接信任，必须把它当作外部代码来审计一遍。3.4 防御恶意Skills的几个具体措施针对这类攻击，我现在的做法是尽量遵守一套基本的防范流程。安装前做人工审查。如果Skills来自开源仓库，至少要把核心逻辑代码通读一遍。重点看它有没有构建网络请求、读取环境变量、访问文件系统之外区域等操作。如果是一个打包好的文件，看不到代码，那就先别急着用，尽量找图形化界面或可读文本的替代方案。严格限制Agent运行时权限。给Agent配置独立的运行目录，让它只能读写这个目录里的内容，对外网络请求默认禁止，只在白名单里放行需要的域名和端口。这就像给Agent建了一个独立工位，它能摸到的东西是有限度的。动手验证请求去向。装好新Skills后，先在一个可控的测试环境里完整跑一次任务，同时开好网络抓包或系统级的网络监控工具，把所有流量记录下来。一旦发现有请求发往不认识的地址，立刻停止使用。不要被"好像跳过验证了"之类的话术迷惑——验证要自己来，别交给介绍页。定期做权限回收。长时间不用的Skills要及时停用或移除，减少暴露在风险中的面积。尤其要定期检查Agent工具链中的access token、API key等凭证，避免出现过期的永久凭证。注意：如果Agent拥有代码仓库的写入权限，恶意Skills可能会诱导它提交包含后门的代码变更。建议在仓库层面为Agent的提交配置独立的账号，并把它设置为需要人工审核才能合入分支，避免直接允许自动推送代码到主分支。4. 三条消息连起来看，Agent开发正进入深水区前面分开讲了三件事，再把它们并到一起看，会发现它们共同指向一个趋势：Agent开发已经从"能跑就行"的阶段，进入"跑得稳、跑得安全、跑得可控"的深水区。4.1 "能跑"和"跑得稳"之间的距离拿Codex / Work的连续改进来讲，工具方在追求"工作流级别的稳定交付"，而不是多一个炫技功能。拿Kolibri开放权重来讲，社区追求的是"自主掌控整个推理链路"，而不是受制于外部API。拿恶意Skills来讲，安全研究者关注的是"Agent在复杂生态中的避坑能力"，而不是简单封禁一个恶意包。这中间的"差之毫厘，谬以千里"，其实就是从Demo到生产环境之间的距离。Demo只要跑通一次就行，生产环境要的是999次实验里有995次正确执行；Demo数据随便放，生产环境一点点数据泄露都是事件；Demo的依赖可以手拉手装，生产环境的每个依赖都要过安全审计。我见过不少团队在尝试Agent化开发时翻车，大多数不是模型能力不够，而是流程和管理没跟上。比如直接给Agent配了过大的权限，比如没有做输入数据校验，比如没有看日志的习惯。这些问题在工具能力快速提升的当下，反而更容易成为瓶颈。4.2 个人开发者和团队应该做哪些准备针对现在的形势，个人开发者和团队可以各自准备几步。对个人开发者来说，我的建议是建立"Agent资产台账"。你手头有哪些Skills、哪些配置项、哪些密钥，是挂在哪个Agent工作流上的，各自有什么权限，都记清楚。别等出问题时才去排查"这里当时装了个什么来着"。另外要养成审查代码生成结果的意识，让AI帮你写代码的话，代码审查占比必须上升。这里的核心原则是，AI写代码的规模越大，人审的实现时间和精力成本越高，越要优化流程，而不是直接跳过。对于团队来说，更关键的是要把Agent安全纳入代码评审流程。团队内部使用Agent生成、引入的第三方代码，在进主分支前，可以通过自动化工具扫描已知恶意模式，配合人力抽查。另外一个比较少有人提的点是团队成员需要在测试环境里沉淀Agent的使用规范，比如哪些任务允许完全自动化执行、哪些任务必须有人工二次确认，这个边界要明确写下来，否则每个成员各自为政，带来隐患。4.3 安全、效率、成本这三件事如何权衡最后聊聊三者的平衡。在Agent开发中，完全不引入第三方扩展，所有东西都自己写，这当然最安全，但开发成本极高，效率优势也丢了。反过来，什么第三方都可能装，什么权限都给，短期看似效率很高，但安全风险爆炸。我现在的策略是搞定"分级授权"的思路：核心链路用自研或经过严格审计的工具，外围辅助任务可以用可信第三方Skills，但一律放进沙箱环境运行。这样可以兼顾效率和安全性。在模型选择上，敏感数据走开放权重的本地部署，非敏感高频任务可以用API调用，成本和安全都能控制在一个合理区间。具体执行时，可以参考这样一个清单：场景模型方案权限策略关键动作内部代码辅助本地部署开放权重独立目录，限制网络访问每次改动代码后做人工代码审查客服/文档问答外部API或本地均可数据脱敏后再出外网定期清理历史会话缓存高风险操作（删表、推送生产）禁止Agent自主执行仅支持人工审批设置双人复核机制第三方Skills引入不依赖任何预装框架先隔离测试再放行网络审计+代码审查，逐项检查这套配置并不复杂，但能把大部分常见的风险挡在外面。深水区的水浑，看不清底下的暗流，但水深也有水深的好处：只要方法正确，往下游潜得更深，看到的东西也会比岸边的人更多。我自己这段时间最大的感受是，Agent工具迭代得快是好事，但越是工具强大，越要给自己立规矩。定了规矩，才能让工具真正成为帮手，而不是制造更多新的麻烦。
这周AI圈子里几条消息凑在一起，信息量其实不小。一边是Codex / Work放话要搞28天连续改进，一边是Kolibri把开放权重的大模型摆上了台面，同时又有恶意Skills攻击Agent的案例被扒出来。这三件事单看各是各的，但放在一起，明显能感觉到Agent开发这条赛道的风向变了：工具的迭代速度在加快，本地化部署的自主权在变大，而安全问题的复杂度也在同步上升。作为一个实际把Agent工作流接到日常开发里的从业者，我对这三条消息的关注点可能跟纯技术新闻不太一样。我更关心的是，Codex / Work这波连续更新到底会用到哪些能力上，Kolibri的开放权重能不能真正降低我们团队的部署成本，以及那个恶意Skills攻击，我们的项目是不是也暴露在同样的风险里。这篇文章就围绕这三个话题展开，结合我自己实践中的一些观察和踩坑经历，聊聊我眼中的趋势和应对思路。1. Codex / Work 28天连续改进，到底在挤什么牙膏先说说Codex / Work这个预告。28天连续改进，一天不落，这个节奏在AI编程工具里确实不算常见。大多数产品都是按里程碑发版，来个2.0、3.0的大版本更新，然后配套写一堆release notes。像这种"连续改进"的承诺，更像是移动互联网时代App那种"周更"甚至"日更"的玩法，把迭代周期压缩到极致，用高频反馈来修正方向。1.1 为什么是"连续改进"而不是"憋大招"我个人的理解是，AI编程助手这个品类跟传统IDE插件有本质区别。传统插件的能力边界是确定的，你定义好功能，做出来，发布，完事。但基于大模型的工具，能力的提升很大程度上取决于模型本身的推理能力、上下文理解能力和对代码库的感知能力，这些能力是可以通过持续调优不断往上走的。既然模型每天都在进步，那产品层面的迭代就不该被发版节奏捆住手脚。从用户的角度看，"28天连续改进"更像是一个姿态声明：团队把自己放在了一个必须持续交付的位置上。这种做法对内部团队的要求极高，意味着每一天都要有东西可交付，倒逼研发管线高效运转。对我这种每天在用工具干活的开发者来说，最直接的好处是反馈回路变短了。今天提交一个bug，可能过两天就修掉了，而不是等上两三个月。另外一个值得注意的点是，Codex / Work背后的思路可能不只是修bug，而是让工具在复杂任务上的表现持续变好。比如处理多文件改动时的上下文连贯性，比如长任务的执行稳定性，再比如对用户代码风格的学习能力。这些能力靠一次大版本更新很难做到位，必须靠持续的小步快跑打磨。1.2 从迭代方向反推产品重点虽然没有详细的路线图，但从AI编程助手的普遍痛点上，大概能猜到28天里重点会动哪些地方。第一是上下文管理的优化。用过AI编程助手的人都有体会，对话一长，它就容易"忘事"。尤其是跨文件重构这种场景，前面改了一个模块的接口，后面让它改调用方的时候，它可能就忘记了前面的约定，导致代码风格不一致。改进的方向大概率会集中在结构化上下文上，让工具能更有效地在长对话中保持对关键信息（比如接口签名、变量名、模块结构）的记忆。第二是工具调用链路的稳定性。Agent类编程工具的核心能力之一就是自主操作终端、编辑器、代码搜索等工具。这个链条上任何一个环节出错（比如命令执行超时、文件路径解析错误、权限不足），都会中断整条任务。连续改进的重点应该是在错误发生后如何优雅地恢复，而不是直接放弃。第三是安全边界。这一点很关键，配合后面要聊的恶意Skills话题，AI编程工具体系里涉及外部代码和插件执行的场景，权限控制必须更精细。比如从云端市场安装一个Skills包，它到底能访问本地文件系统哪些目录、能不能执行shell命令、能不能读取环境变量里的密钥，这些都是需要明确区分和管控的。1.3 开发工作流会被怎么影响如果Codex / Work这波连续改进能兑现，对开发工作流的直接影响有两个。一个是AI辅助编码从"单点辅助"走向"全流程代理"。以前是让AI写个函数、补个测试、解释一段代码，人始终把控着节奏。现在是直接把整个任务丢给Agent，让它自己规划步骤、自己查资料、自己改代码、自己跑测试。这个转变不只是效率提升，而是开发模式的改变，人从每一个细节的执行者，变成了最终结果的审查者。这也是为什么Codex / Work这类工具把"Work"放在名字里，它要处理的不是孤立的代码片段，而是一整条工作流。另一个影响体现在团队协作层面。当AI能更可靠地处理重复性开发任务时，团队中更初级的工作（比如写模板代码、修简单bug、整理测试用例）会逐渐被Agent消化。这会让团队花在代码审查上的比重增加。我见过不少团队已经建立了"AI提PR、人来审查"的流程，这个模式在改进后会更加普及。注意：这类工具的连续更新有个隐形风险——你昨天验证好用的工作流，今天可能因为某个微调就变了。建议不要把Agent当黑盒来依赖，关键的行为变更要跟进changelog，自己的工作流也要定期复盘是否还适配。2. Kolibri开放权重，本地化部署的下一个可选答案聊完工具侧，再看另一个消息：Kolibri开放权重。开放权重这四个字对搞过本地部署的人来说，含金量还是高的。它意味着你可以把这个模型下载到自己的机器上跑，可以做微调，做量化压缩，甚至做一些内部的二次开发。相比只能通过API调用的封闭模型，开放权重给团队保留了极高的自由度。2.1 开放权重和开放源代码不是一回事先说个容易被混淆的概念。开放权重（Open Weights）并不等于开放源代码，你拿到的是训练好的神经网络参数文件，而不是从头训练这个模型所需的数据集和训练代码。这种模式的定位很清晰：官方把模型训练好了，参数给你，你可以拿去部署、微调、商用，但你不能从零复现整个训练过程。这个区别决定了Kolibri的适用场景。它不是用来做学术研究、探索新架构的那种模型，而是用来直接落地到生产环境中的模型。想象一下，训练一个几B甚至几十B参数的模型需要成百上千张GPU卡跑几个月，绝大多数团队没有这个资源。但部署一个已经训练好的模型，一张消费级的GPU可能就够了。开放权重本质上是把"训练成本"和"推理成本"做了一个切分，让团队只需要承担推理侧的硬件成本。2.2 开放权重解决的实际问题在实际工作中，开放权重模型解决的问题往往体现在三个维度。数据隐私是最刚性的需求。我们之前做过一个内部知识库问答系统，数据涉及客户资料和内部策略，这些内容无论如何不能发送到外部API服务去处理。用开放权重模型做本地部署，数据完全不出内网，合规压力一下就小了很多。这里没有模棱两可的空间，数据出境合规是所有做企业服务的人都要过的门槛。如果你是做内部工具，开放权重几乎是唯一可行的模型路线。成本结构的变化也很实际。API调用费用是随着调用量线性增长的，每天几千次问答，长期看是一笔不小的开销。而部署本地模型是一次性硬件投入加电费成本，调用量越大，单位成本越可控。等到调用规模再上来，这个账算下来差别会很大。第三个维度是定制空间。基础模型通过API调用，能力边界基本被限定死了。而开放权重模型可以做微调，让它更贴合你所在领域的术语和表达习惯，这也是API模型很难替代的价值。2.3 部署实操的几个关键点基于我自己的部署经验，如果你要尝试Kolibri这类的开放权重模型做本地部署，有几点值得提前规划。硬件选型要先看模型参数量。几B参数的模型，消费级显卡就能跑，量化后内存占用可以控制在十几GB以内。几十B级别的模型，就需要考虑两张或更多显卡的方案，或者直接用大显存的服务器。量化格式的选择也很重要，以我常用的量化工具套件为例，4-bit量化在推理速度和质量之间是比较均衡的权衡点。官方原版权重的FP16格式准确度最高，但显存占用也大，生产环境更推荐用4-bit或8-bit的量化版本。推理框架需要根据场景选。如果做的是延迟敏感型的交互式应用，比如在线问答助手，选那种支持Continuous Batching、能并发处理多个请求的推理服务，这样可以用一个模型实例服务更多用户。如果做的是离线的批量数据处理，比如给一批文档生成摘要，那并行度和吞吐量优先，牺牲一些推理时延问题不大。另外，开放权重模型的原生能力往往集中在通用对话和代码理解上，要让它在你的垂直场景里表现好，建议先试几次few-shot提示词，看看能不能满足需求。如果尝试后发现效果还不够，再考虑微调。我自己遇到过的经验是，先做提示词工程，后做微调，成本能省不少，而且踩坑概率大大降低。实操提示：模型权重就像是发动机，推理框架是变速箱。权重本身决定性能上限，但推理框架决定你能否把这个上限有效发挥出来。两者需要搭配好，别只盯着权重文件，忽略服务框架的调优。3. 恶意Skills再敲Agent安全警钟第三个消息可能是最需要引起重视的：恶意Skills引发的Agent安全事件。相比编程工具的功能迭代和模型权重开放，安全问题的直接后果更严重，不是影响效率，而是直接威胁到代码资产、数据资产甚至整个服务器环境。3.1 Skills机制为什么会成为攻击面先解释一下Skills在Agent生态里扮演的角色。Skills可以理解为一个能力扩展包，Agent装上某个Skills之后，就学会了执行某类任务。比如安装了一个"代码审查Skills"，Agent就能输出结构化的代码审查意见；安装了一个"PDF解析Skills"，Agent就能读取和处理PDF文件。这个机制本身是好的，它让Agent的能力可以像App一样低门槛扩展。但问题在于，Skills的安装路径天然是开放的。你可以从市场下载，也可以从开源仓库拉取，还可以从个人博客粘贴一段配置。这跟手机上装App很像，区别在于，手机App的上架审核尚且有一套流程，而Agent Skills的分发目前基本没有严格的审核机制，可以说谁都能发，谁都能装。只要这个口子开着，攻击者就有机会在不接触你系统内部的情况下，只通过一个看似无害的Skills将恶意指令送进你的Agent工作流。这种攻击在AI生态里并不少见，它往往不声不响。系统没有被打出明显的洞，账号也没有异常登录，一切看起来正常得很。但数据已经在流向不该去的地方了。3.2 恶意Skills的攻击路径拆解我梳理了一下恶意Skills的典型攻击路径，大致可以分成三个阶段。第一阶段是伪装上线。攻击者会制作一个功能正常的Skills，让它真的能完成你需要的任务，比如确实能解析PDF、确实能生成周报，表面看完全没问题。甚至会在例子里放几个正经的正向输出，引导你在初步验证时认为它"可用"。只有在特定触发条件下，它的恶意逻辑才会被激活。第二阶段是潜伏执行。当Agent调用这个Skills处理真实任务时，恶意指令被触发。这个指令可能藏得极深，可能伪装成"参考文档格式"的提示词，实际上却在引导模型将聊天记录、代码片段、数据库连接信息打包发送到一个远程地址。大多数用户在Agent正常工作的时候不会去检查输出日志里有没有多余的网络请求。第三阶段是横向渗透。拿到初步数据之后，攻击者会尝试更高层级的操作。如果Agent的运行环境还配置了访问其它内部系统的权限（比如能连数据库、能访问密钥管理服务、能操作代码仓库推送分支），攻击者就能通过这些跳板进一步渗透整个系统。这比单独拿到一两份文档严重得多。3.3 攻击案例分析：一次被忽略的异常请求讲一个我实际经历过的案例，可以更直观地说明问题。某次做前端任务时，我从一个第三方仓库下载了一个号称"自动补充CSS样式前缀"的Skills。第一次测试时它表现正常，正确地给几条样式规则加了厂商前缀，我就放心地把它接进了工作流。当时留意到一条异常日志，Agent运行期间往一个不熟悉的域名发了一次POST请求，但我没有细想，以为是版本更新检查机制。后来排查一个网络问题时才发现，那个域名根本不是官方域名。这个Skills在任务执行的某个节点，会把工作目录下的文件列表、项目结构信息以及部分环境变量打包发送出去。幸好那次任务涉及的代码不敏感，否则后果会很难收拾。这件事给我一个教训，第三方Skills不能因为"看起来有用"就直接信任，必须把它当作外部代码来审计一遍。3.4 防御恶意Skills的几个具体措施针对这类攻击，我现在的做法是尽量遵守一套基本的防范流程。安装前做人工审查。如果Skills来自开源仓库，至少要把核心逻辑代码通读一遍。重点看它有没有构建网络请求、读取环境变量、访问文件系统之外区域等操作。如果是一个打包好的文件，看不到代码，那就先别急着用，尽量找图形化界面或可读文本的替代方案。严格限制Agent运行时权限。给Agent配置独立的运行目录，让它只能读写这个目录里的内容，对外网络请求默认禁止，只在白名单里放行需要的域名和端口。这就像给Agent建了一个独立工位，它能摸到的东西是有限度的。动手验证请求去向。装好新Skills后，先在一个可控的测试环境里完整跑一次任务，同时开好网络抓包或系统级的网络监控工具，把所有流量记录下来。一旦发现有请求发往不认识的地址，立刻停止使用。不要被"好像跳过验证了"之类的话术迷惑——验证要自己来，别交给介绍页。定期做权限回收。长时间不用的Skills要及时停用或移除，减少暴露在风险中的面积。尤其要定期检查Agent工具链中的access token、API key等凭证，避免出现过期的永久凭证。注意：如果Agent拥有代码仓库的写入权限，恶意Skills可能会诱导它提交包含后门的代码变更。建议在仓库层面为Agent的提交配置独立的账号，并把它设置为需要人工审核才能合入分支，避免直接允许自动推送代码到主分支。4. 三条消息连起来看，Agent开发正进入深水区前面分开讲了三件事，再把它们并到一起看，会发现它们共同指向一个趋势：Agent开发已经从"能跑就行"的阶段，进入"跑得稳、跑得安全、跑得可控"的深水区。4.1 "能跑"和"跑得稳"之间的距离拿Codex / Work的连续改进来讲，工具方在追求"工作流级别的稳定交付"，而不是多一个炫技功能。拿Kolibri开放权重来讲，社区追求的是"自主掌控整个推理链路"，而不是受制于外部API。拿恶意Skills来讲，安全研究者关注的是"Agent在复杂生态中的避坑能力"，而不是简单封禁一个恶意包。这中间的"差之毫厘，谬以千里"，其实就是从Demo到生产环境之间的距离。Demo只要跑通一次就行，生产环境要的是999次实验里有995次正确执行；Demo数据随便放，生产环境一点点数据泄露都是事件；Demo的依赖可以手拉手装，生产环境的每个依赖都要过安全审计。我见过不少团队在尝试Agent化开发时翻车，大多数不是模型能力不够，而是流程和管理没跟上。比如直接给Agent配了过大的权限，比如没有做输入数据校验，比如没有看日志的习惯。这些问题在工具能力快速提升的当下，反而更容易成为瓶颈。4.2 个人开发者和团队应该做哪些准备针对现在的形势，个人开发者和团队可以各自准备几步。对个人开发者来说，我的建议是建立"Agent资产台账"。你手头有哪些Skills、哪些配置项、哪些密钥，是挂在哪个Agent工作流上的，各自有什么权限，都记清楚。别等出问题时才去排查"这里当时装了个什么来着"。另外要养成审查代码生成结果的意识，让AI帮你写代码的话，代码审查占比必须上升。这里的核心原则是，AI写代码的规模越大，人审的实现时间和精力成本越高，越要优化流程，而不是直接跳过。对于团队来说，更关键的是要把Agent安全纳入代码评审流程。团队内部使用Agent生成、引入的第三方代码，在进主分支前，可以通过自动化工具扫描已知恶意模式，配合人力抽查。另外一个比较少有人提的点是团队成员需要在测试环境里沉淀Agent的使用规范，比如哪些任务允许完全自动化执行、哪些任务必须有人工二次确认，这个边界要明确写下来，否则每个成员各自为政，带来隐患。4.3 安全、效率、成本这三件事如何权衡最后聊聊三者的平衡。在Agent开发中，完全不引入第三方扩展，所有东西都自己写，这当然最安全，但开发成本极高，效率优势也丢了。反过来，什么第三方都可能装，什么权限都给，短期看似效率很高，但安全风险爆炸。我现在的策略是搞定"分级授权"的思路：核心链路用自研或经过严格审计的工具，外围辅助任务可以用可信第三方Skills，但一律放进沙箱环境运行。这样可以兼顾效率和安全性。在模型选择上，敏感数据走开放权重的本地部署，非敏感高频任务可以用API调用，成本和安全都能控制在一个合理区间。具体执行时，可以参考这样一个清单：场景模型方案权限策略关键动作内部代码辅助本地部署开放权重独立目录，限制网络访问每次改动代码后做人工代码审查客服/文档问答外部API或本地均可数据脱敏后再出外网定期清理历史会话缓存高风险操作（删表、推送生产）禁止Agent自主执行仅支持人工审批设置双人复核机制第三方Skills引入不依赖任何预装框架先隔离测试再放行网络审计+代码审查，逐项检查这套配置并不复杂，但能把大部分常见的风险挡在外面。深水区的水浑，看不清底下的暗流，但水深也有水深的好处：只要方法正确，往下游潜得更深，看到的东西也会比岸边的人更多。我自己这段时间最大的感受是，Agent工具迭代得快是好事，但越是工具强大，越要给自己立规矩。定了规矩，才能让工具真正成为帮手，而不是制造更多新的麻烦。