23 篇博文 含有标签「Agent」

文本 Agent 的标配是「工具调用」：模型说一句 search_order("sku")，代码去执行，接口是结构化的。但 2024 年底开始，OpenAI Operator、Anthropic Computer Use、各类桌面/浏览器 Agent 把目标换成了像人一样直接操作电脑——没有 API、没有 DOM、只有像素和窗口。这条技术线工程上比想象中难得多，本文按「感知 → 行动 → 验证 → 成本 → 评测 → 安全」拆开讲，附可运行的骨架代码与实测踩坑。

2026 年 6 月，MCP 完成「无状态核心」改造，HTTP+SSE 双端点退役；定稿版把远程 server 的 OAuth 2.1 变成硬性要求。协议层的来龙去脉，MCP 协议深度解析 和 无状态核心规范解读 已经讲透。但「读懂了协议」和「写得出一个能上生产的 server」之间还隔着一条沟：stdio 帧格式的坑、工具描述怎么写模型才肯调用、鉴权怎么做、客户端怎么接。本文用一段完整可跑的代码把这条沟填上。

系统提示词（system prompt）正在成为 LLM 推理成本里最容易被忽略的部分。一个正经的 Agent 通常要背几十条指令、工具 schema、few-shot 示例和安全约束，动辄几千 token。每次请求都要编码这些 token，decode 时每个生成 token 又要对它们做 attention——长度是线性成本，而吞吐是用户的账单。

2026 年 8 月 19 日，Shopify Engineering 公开了他们在生产环境落地的一项技术：gisting。他们把自己的 GraphQL Agent 系统提示词从约 6000 token 压到约 1500 个 gist token（4:1 压缩），在预测质量不掉的前提下，把 350 RPM 流量下的 TTFT 从 438ms 降到 354ms（-19%）、端到端延迟从 6.8s 降到 4.2s（-38%）、吞吐从 20.2 QPS 提到 23.4 QPS（+16%），最终少用了 14% 的 GPU。这篇文章拆解它背后的原理、训练细节和部署方式。

「这个模型写代码不错」和「这个 Agent 能完成 20 轮工具调用把事办成」是两回事。单轮评测测的是「会不会答」，Agent 评测测的是「会不会把事情办成」——后者涉及状态、工具副作用、长程规划，评测的复杂度直接上了一个数量级。

上一篇LLM 评测工程化讲了单轮文本评测的偏见与校准，这篇聚焦 Agent 场景：评测什么、拿什么当标准答案、怎么写评测骨架、怎么避免评测本身成为成本黑洞。面向已经在跑 Agent 生产流量的后端工程师，不讲科普。

2026 年 8 月 17 日，Wiz Research 公开了一项针对 Snowflake 的安全研究：他们的自主 AI 安全工具「Red Agent」发现并利用了一个 GitHub Actions 脚本注入漏洞，在无人工干预的情况下拿到了 Snowflake 内部 Jira（snowflakecomputing.atlassian.net）的只读访问权限——覆盖工程、安全合规、漏洞赏金项目的数据。漏洞从上线到被攻破只有 5 天，而引入漏洞的 PR 的 co-author 是 "Copilot Autofix powered by AI"。

对做 AI 工程的人来说，这是一次教科书级的「反噬」案例：AI 写代码的能力正在快速商品化，但 AI 生成代码的安全治理才刚刚开始。这篇文章把整个事件拆开：漏洞怎么来的、为什么做了 sed 转义还是被注入、Red Agent 如何从执行报错里自我纠错完成利用、以及工程上到底该加哪些护栏。

2026 年 8 月，智谱发布 GLM-5.3，官方把这次更新的关键词定成两个：Coding 和 安全。前者不意外——上一代 GLM-5 的编程能力已经逼近闭源第一梯队；真正值得注意的是后者：模型发布前两周，智谱联合清华、南开及多家企业做了密集红队测试，累计发现漏洞 2404 个（初筛去重后），其中 1088 个中高危，覆盖系统内核、浏览器引擎、开源基础组件、互联网应用与协议等 220 个项目。在 CyberGym 白盒代码审查评测上，GLM-5.3 拿到 84.5%（上一代 5.2 为 77.2%），成为开源阵营里分数最高的安全模型。

为什么一个 Coding 模型要死磕安全？答案很直接：Coding Agent 已经从"给一段代码"进化到"读整个仓库、改文件、跑终端、装依赖、参与部署"，拿到的权限越来越高，一次判断失误的后果被成倍放大。 当 AI 以机器速度写代码、操作系统时，安全必须跟上机器速度。这篇文章以 GLM-5.3 的实测为样本，拆解 Coding Agent 安全能力的三层结构：白盒审计、漏洞推理、证据分级——并讨论这套能力该怎么评测、怎么用。

2026 年 8 月中旬，Qwen 开源了 Qwen3.8-27B：270 亿参数的稠密（Dense）原生多模态模型，Apache 2.0 协议。两个数字让它在一众开源模型里显得特殊——262K 原生上下文（YaRN 可外推到 1M）和量化后 24GB 显存可部署（RTX 3090/4090 级别）。官方 benchmark 里，它在 SWE-bench Pro 上比 Claude Opus 4.6 Max 高出 8.3 分，QwenSWEBench 上领先 15.2 分。

对做工程的人来说，这条新闻的真正信号不是"又一个榜单刷分"，而是：长上下文 + 强 Agent 能力开始向消费级硬件下沉。这背后是架构层面的变化——Qwen3.8-27B 的 64 层里只有 16 层是标准 Attention，其余 48 层换成了 Gated DeltaNet 线性注意力，按"三层线性 + 一层完整 Attention"循环排列。这篇文章拆解这个设计到底解决了什么问题、KV Cache 的账怎么算、以及部署时要注意什么。

单 Agent 的瓶颈很直观：上下文窗口有上限、一次只能专注一件事、越长的对话越容易跑偏。于是大家开始拆多 Agent——一个检索、一个写代码、一个质检、一个做安全审查。但真正上手做过的人会发现，多 Agent 协作的难点从来不是"让 Agent 会聊天"，而是编排（Orchestration）：任务怎么拆、谁先谁后、上下文怎么隔离、结果怎么合并、一个挂了怎么办。

本文不重复上一篇 A2A 协议（A2A 协议深挖），那解决的是"Agent 之间怎么发现和通信"的协议层；这篇解决的是"有了通信之后，你怎么组织它们干活"的工程层。协议是网卡，编排是大脑。

很多人到现在还分不清 MCP 和 A2A 的区别，把它们当成一回事。一句话讲清：MCP 是给 Agent 接外设的 USB 接口，A2A 是给 Agent 联网的网卡。MCP 让一个 Agent 用统一方式调用工具、文件、数据库；A2A 让多个 Agent 之间互相发现、协商、委托任务。上篇拆解了 MCP 2026-07-28 新规范（MCP 规范解读），这篇聊它的姊妹协议 A2A。

一个 agent 连续跟你工作三周后，突然忘了你的数据库密码格式约定、忘了上周定的接口规范——这不是 bug，是它的记忆系统根本没设计。上下文窗口是「RAM」，断电（会话结束）就没了；真正的记忆系统，是往 RAM 之外再加一层「硬盘 + 索引」。