GPT-5.6 发布、微软掏了两套新工具，这些东西本周都算新闻。但真正让所有人放下咖啡杯转发的，是 GitLost —— 一伙安全研究员让 GitHub 的 AI agent 把私有仓库内容吐到了公开页面上。之前大家还在争论 "给 agent 读私有代码安不安全"，现在好了，答案是 "不安全"。
GitLost：让你亲眼看见私有仓库怎么飞出去的
538 个投票，HN 本周最高。Noma Security 放出了完整的攻击演示：先让 GitHub 的 AI agent 处理一个公开仓库，里面悄悄嵌入了一份指向私有仓库的指令。Agent 照做了，把私有 repo 的源码当上下文写了出来。
技术上不复杂，像是一个精心构造的 "请君入瓮"。但问题在于——现有的 agent 安全机制对这类跨仓库引用几乎不设防。它不检查 "这个文件是谁让你读的"，只负责执行。
我猜接下来几个月 GitHub 得赶紧补上下文隔离。现在想让 agent 帮你写代码、读文档，又怕它不小心把内部项目名写到公开 issue 里去的人，应该睡不好觉了。
文章非常值得读：GitLost: How We Tricked GitHub's AI Agent into Leaking Private Repos
微软这周：Flint 画图，OfficeCLI 读写，GPT-5.6 接盘
微软一口气放了三样东西，各自方向不同：Flint 是个可视化语言，给 agent 提供一种声明式的图表输出格式。你看 agent 的思维链、调用栈，以前得扒日志，现在能画成流程图。代码和 demo 在 Microsoft Flint Chart 上，适合 debug 场景，但我觉得更关键的是 —— 它尝试给 agent 的 "输出表现层" 定一个标准。各家 Agent platform 都在抢这块心智，Flint 现在开源，API 挺干净，能拿来用一用。
OfficeCLI 更务实：让 agent 通过命令行读写 .docx、.xlsx、.pptx。零外部依赖，直接 jail 掉那些调用 COM 或 OpenXML 库的复杂方案。配合 GPT-5.6 在 Microsoft 365 Copilot 里成为首选模型（见 OpenAI 声明），以后 Office 文档编排可能会彻底自动化——但前提是 agent 先搞清楚 "标题要用几号字" 这种人类约定，而不是把整段文字塞进文本框。
GPT-5.6 本身的发布稿写得很软性，强调 "每 token 更多智能、更强性价比"。OpenAI 还悄悄上线了 ChatGPT Work 模式，说是 "agent 可以在你的 app 和文件之间串连几个小时"（https://openai.com/index/chatgpt-for-your-most-ambitious-work）。听起来像 Copilot 的升级版，但没公布太多技术细节。按我现在看，Work 模式本质就是延长了 agent 的 session 生命周期，配合 GPT-5.6 更高 token 吞吐，能跑之前跑不完的 multi-step 任务。
ArXiv 这周：记忆、搜索、调度——都不容易
这周 ArXiv 出了几篇跟 agent 系统短板直接相关的。
《Remember When It Matters》（https://arxiv.org/abs/2607.08716v1）搞了一个主动记忆模块：agent 在长轨迹里自己判断哪些信息 "以后还会用到"，主动把它缓存成带索引的记忆块。思路不新，但实验设计扎实 —— 在 multi-hop QA 和长程机器人任务上，记忆召回率提升 20 多个点。问题在于：主动记忆的显存成本不低，上下文窗口 128K 的时代，还值得专门塞一个记忆模块吗？也许 6 个月后回头会被打脸，但如果 context window 真能到 1M，主动记忆可能就多余了。
《WebSwarm》（https://arxiv.org/abs/2607.08662v1）做的是多 agent 递归搜索：一个 agent 负责划分子问题，另一些独立搜，再汇总。听起来像 WebGPT 加了个管理器，但它在需要 "深度+广度" 的复杂搜索任务上明显优于单 agent ReAct。我对这类方案有点怀疑——编排开销真的小于单 agent 的长上下文损失吗？实验里给的指标是 "搜索完成率"，但没提 token 消耗对比。谁有空做一下对比实验？
《SMetric》（https://arxiv.org/abs/2607.08565v1）是篇实在的系统论文：现有的 LLM 调度器（如 vLLM, TGI）是为人类用户优化的 —— 优先保证每个请求的首 token 延迟。但 agent 场景完全不一样：agent 不关心首 token 快 50ms，它只关心 整个会话的吞吐。作者提出 session-centric 调度，把同一 session 的多个请求捆在一起调度。这个方向对部署 agent 服务的人很关键，不过他们还只做了模拟，没在 vLLM 上实装。
还有一篇讲能源市场 agent 的 SolarChain-Eval，以及讨论 agent 不平等的 Context Access Divide —— 后者讲的是 "有些人能用 agent 深度分析，有些人只能拿到简单答案"，从社会层面看问题，但每周看 ArXiv 的读者可能更关心技术细节。
Coding Agent 现状：Zuckerberg 说不行，Databricks 说还行
马克·扎克伯格在内部讲话里说 "AI agents 进步没有预期快"（https://techcrunch.com/2026/07/02/mark-zuckerberg-tells-staff-that-ai-agents-havent-progressed-as-quickly-as-hed-hoped/）。与此同时，Terry Tao 写了一篇博客（https://terrytao.wordpress.com/2026/07/11/old-and-new-apps-via-modern-coding-agents/），用 coding agent 把 20 年前的一个老数学工具重写了一遍，直接跑通。Databricks 则在自家百万行代码库上做了 benchmark（https://www.databricks.com/blog/benchmarking-coding-agents-databricks-multi-million-line-codebase），结论是当前 agent 能处理常规任务，但在深层依赖追踪上依然不稳定。
两件事不矛盾：Zuckerberg 说的是 general-purpose agent 还不够好，Terry Tao 和 Databricks 说的是，给定一个边界清晰的好任务，agent 已经能产出可用结果。关键看你怎么定义 "进步"。另外，有一篇最小对研究（https://arxiv.org/abs/2605.20049）发现，代码整洁度对 agent 修复 bug 的成功率有显著影响——脏代码会让 agent 误判 30% 以上。所以与其抱怨 agent 笨，不如先把代码库清理干净。
还有一个好玩的项目：100 行 Lisp 写 agent（https://thebeach.dev/posts/lisp-agent/），简洁到离谱，拿来做教学或者快速原型很好。但不适合生产。
还有两个值得扫一眼
Mindwalk 能把 coding agent 的 session 回放到代码库的 3D 地图上，有点像给 agent 装了个行车记录仪。debug 的时候挺有用，尤其是 agent 跳到你不理解的文件时。
FableCut 是个零依赖的浏览器视频编辑器，可以用 agent 驱动。演示里 agent 按提示自动剪了一段 3 分钟的视频。但这个方向我感觉还早——视频编辑的审美很难用 current agent 控制，挺容易剪成鬼畜。
最后，别忘了 OpenAI 的 Bio Bug Bounty（https://openai.com/index/bio-bug-bounty），针对 GPT-5.5 的生物学安全评估，最高奖金 10 万美金。如果你懂分子生物学又喜欢搞红队，这可能是本周最值钱的 side project。我不信 agent 能在这周突然飞跃，但安全这块，赔钱永远比赚钱快。