上午我本来是打算把 Agent 架构演进的笔记整理成文的结果刚写了半段群里就炸开了锅LiteLLM 的某个公共实例又出现密钥泄露的讨论。等我抽出时间把这周的模型动态看完天已经黑了。这篇简报与其说是在给你画知识图谱不如说是我今天实操下来的一个真实切片。核心就三块Agent 架构演进怎么看、LiteLLM 安全事件怎么复盘、开源模型最近的发布会上哪些方向值得重点关注。如果你还没有把这些概念串起来也不用急这篇文章我会逐一展开。尤其是安全那一段我把完整的排查链路整理成了可以照着走的步骤后面遇到类似问题可以直接复用。1. Agent 架构演进从“能跑通”走向“扛得住”的四个阶段1.1 四代架构模式先搞清楚你在第几代很多人一聊到 Agent 就说“我调了下工具调用挺顺的”。但你真正把 Agent 放进生产环境之后就会发现工具调用只是地基架构才是决定天花板的东西。从这几年的演变来看Agent 架构大致走过了四个阶段我习惯把它们叫“四代模式”。第一代是“裸工具调用”。模型拿到用户问题触发了某个 function call代码执行完把结果丢回给模型。这个模式用于单步工具、表单填写、简单查询完全够用但一旦任务链变长模型就会陷入“一次只处理一个方块”的短视状态。第二代是“ReAct 单干户”。模型自己循环“思考-行动-观察”外部框架只负责把三轮流程兜住。这个阶段的代表作就是各种基于提示词模板的智能体框架典型收益是能解决多步逻辑任务典型问题则是上下文污染。任务跑到第 8 步时前面的中间结果已经挤满了窗口最后决策质量断崖式下降。第三代是“主管与员工”模式。主管模型负责拆解计划和分配子任务子 Agent 各干一段最后再由汇总模块收敛结果消息走总线或者事件队列多个 Agent 之间并行协作。这个阶段的好处是职责分离、扩展性好坏处是状态管理变难。你经常会遇到子 Agent 跑完了但主管的“全局视图”还没更新或者几个子 Agent 各说各话、结果相互冲突。多 AI 协作不是简单几条消息互发而是“共享上下文 统一工作簿”的产物这是很多人容易踩的坑。第四代我称之为“技能库 上下文工程 记忆分层”的组合式架构。模型不再是唯一主角Prompt 模板、工具描述、记忆检索、安全护栏都变成显式的构件。技能包把常见的任务处理方式固化成可复用资产记忆部分做分层设计长短期分开存需要哪一段才调哪一段。这一步才算真正进入“可运维”水平。做个生活化类比第一代像给实习生发了个计算器第二代像给同一个实习生一份完整办事流程让他自己跑第三代像搭了个部门经理分配活、员工执行但部门之间信息同步靠开会容易开乱第四代则是把工作手册、知识库和审批流都做成了系统里的基础设施换谁进来干活都能保持同一套标准。我的建议是如果你现在还在第二代架构上硬扛生产流量先把“记忆分层”和“技能复用”补上比换一个更重的框架更实惠。1.2 Harness 和 Agent 的区别架构是容器的骨架不是模型的自由发挥“harness 和 agent 区别”这个搜索热度很高但真正能把两者边界说清楚的资料少之又少。我直接给你一个简单定义Agent 是指那个做出“下一步选哪条路”决策的模型本身Harness 是指承载决策的所有外围机制包括循环控制、提示词模板拼接、工具执行与权限、日志、记忆检索引擎、成本统计和安全护栏。听起来很学术换一种说法你就明白了。Agent 是“大脑”负责在每一个时间点判断执行什么动作、调用哪个工具、什么时候停止Harness 是“身体”和“工作流系统”负责把你的判断变成可重复执行的流程。大脑再聪明身体不稳也会摔跤。实操中我见过两类极端问题。第一类是“全部塞进 Prompt”把 Harness 该干的检索、归一化、去重、权限校验全都让模型自己看着办。这会导致 Agent 的上下文被无意义信息占满输出不稳定。第二类是“重 Harness 轻 Agent”把整个 Agent 写成几百行 if/else 状态机模型只是一个按钮偶尔遇到预期外输入就直接退化成“听不懂”的机器人。我的建议是让 Harness 管“确定性的东西”让 Agent 管“非确定性的东西”。比如“调用哪个工具”可以给 Agent 更多自由而“工具的调用参数该怎么校验”“超过多长时间必须交给人工复核”这一类规则由 Harness 强制执行。这是目前我看到的最稳妥的架构原则。1.3 框架与编排选型不是选最火的是选能控住流程的关于 Agent 框架市面上的东西多到让人选择困难。有人直接上 LangGraph 做状态流有人用事件队列自己排编排还有人拿 Rust 重写运行时图的就是并发和低延迟。我的选型逻辑很简单先想清楚你是要“显式流程”还是“隐式流程”。显式流程适合内部工具、表单填写、客服工单这类流程相对固定的场景。流程模板亮在明面上模型只是在约定好的节点上做判断和执行。这种情况下框架的重点是状态流转、重试、超时和审计。隐式流程适合开放探索型任务比如“分析这个仓库并给出重构方案”“整合多个文档做一份行业报告”。此时模型需要更自由的决策空间框架的关键在于“护栏”比如工具白名单、最大步数限制、敏感操作二次确认。在编排方式上小团队起步阶段完全不需要上复杂消息总线先把单一 Agent 的循环写清楚再用子 Agent 模式扩展到了多业务线并行、多 Agent 协作频繁的场景再把消息队列、任务持久化、工作流引擎引入。换框架是很贵的但比框架更贵的是还没弄清自己是哪种流程就盲目上战斗力。还有一点值得留意基于 Rust 写的 Agent 运行时这两年在性能指标上很能打尤其在高并发工具调用场景下token 吞吐和内存占用都有明显优势。如果你要“扛并发”可以优先看看这类运行时方案但不要只看语言要同时评估社区成熟度。2. LiteLLM 安全事件复盘一条没进 .gitignore 的配置能捅出多大的娄子2.1 事件现场从异常账单到网关彻底失守LiteLLM 这类工具现在几乎是 Agent 团队的标配它可以把 OpenAI、Anthropic、国内各家模型统一成一个网关入口接上 CC Switch 这类模型切换工具后团队切换模型只需改一行配置。但副作用也很明显它成了所有模型密钥的“集散地”。一旦它出事你几乎没有缓冲。我们在今年的 3 月 25 日早上遇到一次真实的安全告警。最初只是账单异常某个供应商账户在凌晨两个小时内消耗了前一天 40 倍的 token。起初第一反应是“是不是有用户在跑批量任务”但查看调用日志后发现请求的来源 IP 分散到五六个国家而且走的都是同一个 Access Token。再深查才发现网关的 master key 被人拿到了攻击者直接通过网关的管理面板把所有上游模型供应商的密钥都拉了出来然后用这些密钥跑自己的业务。整个过程让人后背发凉的点在于失守的根源不是“通过某个高级漏洞打了进来”而是一次典型的配置泄漏。我们当时把部署用的配置文件顺手提交进了私有仓库文件里包含.env路径的引用而.env中有 master key 和多个供应商 key仓库虽然标记为私有但权限控制做得不严最终被外部扫描工具盯上。加上网关上没有限制“管理端口”必须内网访问攻击者直接朝着管理面板去获取密钥的过程毫无阻碍。2.2 完整排查链路照这个顺序走别慌如果你也遇到类似的可疑消耗我给你一套我们当天实际用到、确实把问题收敛住的排查顺序先熔断网关上的高消耗路由将所有请求切到备用网关或直接临时拒绝非白名单来源的访问。这一步的目的不是找到原因而是先止血。导出最近 6 小时的调用日志筛选出异常 Access Token按调用次数和 token 消耗倒序排列。谁用得最多先查谁。用异常的 Access Token 反查来源包括最早的调用时间、来源 IP、User-Agent、调用了哪些模型。如果来源 IP 与你业务正常的地区分布完全不符基本可以确认 Token 已泄露。接着排查密钥是怎么出去的去 Git 仓库跑git log --all --oneline -p -- .env看有没有配置文件进入过版本历史同时检查 CI 日志、部署脚本、聊天截图渠道里是否出现过密钥。如果仓库历史里真的出现过问题就基本定性了。最后确认影响面把攻击者的调用记录和合法业务的调用记录区分开看攻击者是否只是通过网关“代跑”还是进一步尝试读取配置并窃取了其他系统权限。写一份时间线出来什么时间点配置入库、什么时间点第一次异常调用、什么时间点外部 IP 开始集中访问、什么时间点你发现问题并断网。时间线是后面做安全复盘和向团队同步的关键材料。这套链路的核心原则是先断出口再查入口最后固化证据。千万不要一边攻击者还在跑量一边慢慢翻日志分析那是给自己创造更大的账单。2.3 修复方案与安全默认值从“事后救火”改到“源头设防”问题查完之后修复动作不要只停留在“删掉密钥、换一个”。我们做的改造有四层每一层单独拿出来都不复杂但叠在一起效果非常明显。第一层密钥管理全部接入 Secret Manager。把.env里的明文 key 全部迁移到 HashiCorp Vault 或云厂商的 Secret Manager网关启动时通过服务身份临时读取日志里不打印任何 Authorization 头。权限隔离做到“每个服务一个角色”不能让所有服务都能拿到全部模型密钥。第二层把 LiteLLM 的管理面和数据面分开。管理面板不要跟着业务端口一起暴露到公网可用独立内网端口或通过跳板机访问ui: false是默认值除非你有明确的管理需求否则不要打开。对外请求一律走 API 网关做认证和授权网关层面只放行业务 API校验 JWT 或 mTLS。你可以把它理解成“家里大门只留一扇其他门全部封死”。第三层给每个供应商密钥配置限额和告警。LiteLLM 支持max_budget、max_parallel_requests、rate_limit等参数。我建议至少在配置里为每个模型添加分钟级限额并设置余额耗尽或调用量突增告警。下面是可参考的最小配置片段litellm_settings: budget: 100.0 rate_limit: 60 model_list: - model_name: openai/gpt-4o litellm_params: model: openai/gpt-4o api_key: os.environ/OPENAI_API_KEY max_budget: 50.0 max_parallel_requests: 5第四层在仓库和 CI 里安装密钥扫描插件。Gitleaks、TruffleHog 都可以配合 pre-commit 钩子只要提交内容包含疑似密钥就直接阻断。我们后来还把“仓库权限重新审核 团队定期轮换密钥”写成了季度例行动作。原因很简单密钥轮换不是出事了才做而是每固定一段时间就该做一次很多东西在泄露时你根本察觉不到。关于 LiteLLM 安全我再多说一句。我见过很多团队把 LiteLLM 当成一个纯路由工具请求进来转出去就完事完全没想过它会成为整个 AI 基础设施中最需要防护的节点。它确实只是做转发但正因为所有模型 key 都在它这里集中它实际上成了你 AI 业务的半个“防火墙”。安全维度上请把它当内网核心服务来对待。3. 开源模型新进展瘦身、推理、Agent 前置3.1 三个值得关注的趋势别只盯着排行榜今天聊开源模型我不太想展开任何一家新模型的具体分数而是想把 3 月这一轮的进展归纳成三个趋势你顺着趋势去看具体发布会更有判断力。第一个趋势是“推理能力开始往小模型下沉”。过去推理模型是超大参数的专属但现在很多研究团队已经把长链推理和反思能力压缩进了 30B 以下的中小模型。这意味着 Agent 的本地部署门槛大幅降低个人团队也能在工作站上跑一个能自己做规划、自己纠错的 Agent 底座。第二个趋势是“开源生态从只给权重走向给全套配方”。权重文件只是开源模型的一小部分数据配比、训练脚本、评测集、微调模板也开始被陆续公开。对工程团队来说这套配方比单个模型的榜单分数值钱得多。你可以基于它做领域增强而不是从一个预训练权重开始瞎摸。第三个趋势是“工具调用能力成为模型评测的核心维度”。以前大家比的是知识问答和代码生成现在越来越多的 Agent 场景要求模型输出结构化工具调用序列、在误调用时主动更正、在信息不足时明确提问。开源模型的开发者也越来越意识到跑分高不一定能当好 Agent工具调用的“格式稳定性”和“失败恢复能力”才是关键。我对开源模型的具体选型建议是把“是否能稳定输出工具调用”作为第一道筛子把“上下文使用效率”作为第二道筛子再去看传统跑分。一个模型如果没有工具调用能力光凭着知识问答分数高在做 Agent 时基本只会让你多花调试时间。3.2 端侧模型与 Agent 工程从云上消耗转向本地记忆和开源模型进展同步的热词是“端侧”“本地”“个人知识库”。这里绕不开一个明显趋势Agent 不再只是云端服务的产物越来越多会跑在本地。比如很多人开始把 Hermes Agent 这样的本地智能体跑起来和 Obsidian 知识库打通让 Agent 在本地检索笔记、整理资料、生成写作草稿。为什么这类本地 Agent 突然受欢迎原因是云上模型 API 在长对话场景下成本会快速失控你每问一次都要把几十条历史消息全部带上token 费用累积得让人肉疼。而本地模型没有增量 API 费用跑起来之后只有硬件成本再加上本地数据不出机器也解决了隐私问题。实际操作层面如果你打算做本地 Agent我建议按这个思路配置模型选择量化和 GGUF 格式的推理版本用 llama.cpp 这类轻运行时加载记忆库单独放在 SQLite 或本地向量库里所有跨天记忆都写入本地文档而不是全部堆积在上下文中。Agent 每天开工时先检索和当天任务相关的记忆清空不相关历史再开始跑任务。这个模式我给好几个团队推荐过都反馈上下文干净之后输出质量稳定了不少。3.3 别只看榜单把开源模型放进自己的 Agent 里跑一轮最终验证真正决定一个开源模型能不能上生产不是发布文章里的示例而是“放进你自己的 Agent 任务集里跑一轮”。榜单只能告诉你模型的通用能力区间无法告诉你“它能不能按你的工具协议输出正确 JSON”“能不能在你的领域术语下不胡编”“能不能在长流程里不丢目标”。这些差异只有跑评测集才会暴露。我的做法是维护一份“Agent 任务集”大概 20 个任务每个任务包含 4-6 个子步骤覆盖文档解析、工具调用、记忆检索和失败恢复。换新模型之前先把这批任务跑一遍记录成功率、平均步数、平均 token 消耗。如果新模型分数高但 token 消耗翻倍那就不划算如果分数略低但 token 消耗少 30%反而值得考虑。这里要单独提醒一个点Agent 的真实成本不只是上下文窗口里的 token 数而是“重试次数”。很多开源模型在工具调用上格式稳定性不足每天出几十次参数错误就得重试几十次。重试带来的不只是成本还有循环卡死、状态错乱。所以评测时一定要统计“首次调用成功率”这个指标比平均分更有工程价值。4. Agent 工程化的三块压舱石记忆、Skill 与 AI 原生研发4.1 记忆设计上下文是弹性工作区不是无限档案室现在很多模型都宣传超长上下文窗口动不动就是 128K、256K 起步但真实工程里我不建议把上下文当成无限档案室来用。上下文越长检索难度越高模型越容易被无关历史带偏成本也越高。真正可靠的设计是分层记忆短期记忆存当前任务的工作集比如临时变量、待办清单中期记忆存单个任务的进展状态长期记忆通过向量库存储重要信息需要时才动态检索拉入上下文。最粗暴但有效的实现方式是这样让 Agent 每次完成任务后自主生成一段“记忆总结”用结构化格式写入记忆库。新任务开始时Agent 先从记忆库检索与当前任务相关的历史过滤后拼接进系统提示词。有些团队会把这一步做得很重比如引入异步记忆写入、记忆压缩算法、遗忘机制。我的建议是先用最简单的“任务级摘要 向量检索”跑通之后观察哪里在实际出问题再迭代加复杂度。有一句经验值得记住记忆设计不是把模型变成“什么都记得住的神”而是让模型“在该想起的时候想起正确的东西”其他的忘了反而是优势。4.2 Skill 技能包把 Prompt 从“咒语”变成可复用资产Agent Skill 这个方向过去两年变化很大尤其是 Claude Agent Skills 那套思路本质上是在说一件事把工具调用之外的“专业操作流程”也做成可插拔的模块。一个 Skill 可以是一套 Instructions、一组参考示例、一个校验规则集甚至是一段小脚本它解决的是“让多个 Agent 在同一个场景下做事的风格一致”问题。实操上我建议每个团队都维护一个技能包目录。比如“代码评审”技能包、 “数据分析报告”技能包、“客服工单处理”技能包。每个技能包包含四件事适用场景描述、执行步骤清单、输入输出约定、常见错误与规避方法。模型在进入对应场景时再加载对应技能包而不是把所有技能全部塞进系统提示词。这么做的好处是Prompt 保持精简技能包按需加载可复用程度也高。将来你想把同一套技能迁移到另一个模型上只需要把技能包原样带过去。“Agent anywhere”这个趋势喊了很久但真正落地的形态其实就是技能包标准化后Agent 可以随处迁移不再绑定某一个特定模型或者某一个单点框架。4.3 AI 原生研发范式测试、代码、文档都开始被 Agent 重新组织最后我想聊聊 “AI 原生研发范式”在工程团队里的实际影响。过去我们写代码、写测试、写文档是“人驱动”现在越来越多的团队开始“Agent 驱动”用 Agent 生成测试用例、用 Agent 跑全量回归、用 Agent 整理变更影响范围。特别是“AI 测试开发”这个方向比我预想的更早进入实用期。以前测试团队最头疼的就是边界用例覆盖不足而现在可以让一个测试 Agent 盯着产品变更描述去自动生成边界条件再把边界用例丢给另一个 Agent 执行和断言。多 AI 协作的场景在这里体现得特别明确一个 Agent 负责“生成”另一个负责“验证”两者共享同一个任务上下文最后把结果汇总到一个可审计的状态流里。需要注意Agent 生成的测试代码不能直接进主干。我现在的团队流程是“Agent 初稿 人工 review 自动化验证三明治”每一步都有独立把关。如果跳过人工 review测试代码一旦出错会变成“错误在验证错误”最终比没有测试更危险。另外IDE 生态里的 AI 插件也在悄悄改变日常开发节奏。像 Fitten 这类插件已经能完成不少琐碎的代码生成和补全工作但这些工具主要解决“单点效率”离真正的 AI 原生研发还差一个维度。因为没有一种 Agent 能全程接管一个复杂产品的上下文漂移你仍然需要人在环里做决策。这个度需要团队自己摸索但方向已经非常清晰Agent 不是在替换你的工程师而是在替换那些没有上下文依赖、确定性强的重复劳动。我最后再说一点个人的习惯。现在每次搭建 Agent 相关项目我都会预留三样东西一份密钥权限清单、一份可复用的技能包目录、一份任务的评测集。密钥清单解决安全事故技能包解决切换迁移评测集解决模型选型。这三样东西听起来不如“跑通一个 Demo”有成就感但真正把项目放到生产、放到半年之后回头看你会发现它们才是把项目撑住的关键。今天这份简报提到的东西几乎都能落到这三件事上希望能给你一些用得上的参考。