Grok Build 0.1 的关键不是又多一个 coding model，而是 xAI 明确把“coding agent 用模型”作为 API 商品拆出来。模型被推荐用于 Grok Build、Cursor、Hermes Agent、OpenClaw、Kilo Code、OpenCode 等 harness，这说明它的目标接口不是普通 chat，而是会执行工具、处理 diff、调用 MCP、长期跑任务的 agent loop。

价格和速度也有选型意义。100+ tokens/s 与 $1/$2 per million tokens 让它更像 coding agent 的 fast execution / subagent 模型，而不是只跑最高难度设计任务的旗舰 reasoning 模型。对多模型 coding stack 来说，这类模型适合放在“快速实现、局部调试、工具调用密集”的路由层，复杂架构判断再交给更慢更强的主模型。

Claude Code 这组变化说明 coding agent 已经进入“客户端也要像生产系统一样治理”的阶段。plugin 不再只依赖 marketplace，agent dispatch 不再只靠临时 prompt，OTEL 不再只看 token usage，而是开始记录 tool decision 级别的参数。这些都是团队把 agent 放进日常工程流后自然需要的能力：谁调用了什么工具、哪个 skill 生效、哪个 agent 身份执行、出了问题能不能追踪。

disallowed-tools 和 plugin marketplace allowlist 的方向尤其重要。skill 一旦变成可分发资产，就会带来 supply-chain 和权限边界问题；把工具禁用规则写进 skill frontmatter，把可推荐 marketplace 交给管理员控制，比单纯依赖用户批准弹窗更接近企业部署需要。它也呼应 NVIDIA verified skills 和 SkillOpt 这类工作：agent 能力包正在变成可审计、可路由、可优化的工程对象。

Step-3.7-Flash 代表另一个方向：不是把 agent 能力压进小模型，而是把大规模多模态模型开放给部署栈和企业 GPU 生态。多模态 agent 要处理截图、文档、图像、视频帧和文本任务，单纯 text LLM 的工具调用能力不够，必须让感知和推理在同一模型或紧耦合模型组里完成。

值得注意的是它同时出现在 HF 热榜和 NVIDIA 企业部署内容里。前者说明社区开始试用，后者说明厂商在优化可运行路径。对开发者来说，真正重要的不是参数规模，而是它能否在 vLLM / TensorRT-LLM / NIM 等 serving 路径上以可接受延迟跑起来，并接入现有多模态 routing、safety 和 observability。

agent skill 过去常被当作手写提示词或一次性生成的说明文档。SkillOpt 的核心转变是把 skill 看成“可训练但人类可读”的参数：模型权重不动，运行时额外模型调用不增加，优化发生在部署前的 skill 文本上。这非常适合企业场景，因为 skill 可以代码审查、版本管理、回滚和迁移，比微调权重更容易治理。

结果也很强。论文报告在 GPT-5.5 上，SkillOpt 相比 no-skill 平均提升 direct chat +23.5、Codex loop +24.8、Claude Code +19.1，并且优化出的 skill 能跨模型规模、跨 Codex / Claude Code execution environment 和相近数学 benchmark 迁移。它把“从轨迹中提炼流程知识”变成可验证优化问题，而不是依赖 prompt engineer 直觉。

文档智能最危险的失败不是答错，而是答对了但引用错了。法律、金融、医疗、审计等场景需要知道结论来自哪段条款、哪格表格、哪张图，而当前 Doc-VQA benchmark 通常只看 final answer，掩盖了“模型撞对答案但证据虚构”的问题。CiteVQA 把这一点做成可量化指标。

这会直接影响企业 RAG 和 document agent 的评测方式。未来文档系统不能只报告 exact match 或 LLM judge answer quality，还要记录 citation region、bbox overlap、证据链完整性。PaddleOCR-VL、LocateAnything、CiteVQA 这几条线放在一起看，document AI 正从“抽文本给 LLM”转向“可定位、可验证、可审计的视觉证据系统”。

agent 记忆的核心矛盾是：云端模型更强，但用户长期记忆里最有价值的信息往往也最敏感。传统 masking 把敏感值替换成 ***，隐私是保住了，但模型无法形成“同一类实体、同一类偏好、同一类约束”的语义记忆。MemPrivacy 的 type-aware placeholder 把真实值留在本地，把语义结构留给云端，是更实用的折中。

这类机制会成为 personal AI 和 enterprise assistant 的底层组件。用户希望模型记住“我的主治医生”“我的客户合同”“我的内部系统账号”，但不希望这些具体值进入云端长期状态。MemPrivacy 的端侧识别、云侧记忆、本地恢复模式，和 Unabyss、OpenHuman、ContextPool 这类 persistent context 工具属于同一个趋势：长期上下文必须变成可控数据系统，而不是聊天记录自然堆积。

随着 frontier model 已经在 IMO 级任务上接近金牌水平，研究级数学评测需要从“解难题”升级到“知道什么时候问题不成立、何时应拒答”。Soohak 的 refusal subset 很重要，因为数学研究里识别 ill-posed problem 和不充分条件，本身就是能力的一部分。一个模型如果对错误题目也给出自信证明，在实际科研中比答错更危险。

数据集暂缓公开以防污染，只开放评估请求，这也反映了新一代 benchmark 的现实困境：公开数据越快，越容易进入训练集；不公开又影响复现。对 AI4Math 方向，Soohak 提供的信号是当前 frontier reasoning 仍有巨大 headroom，尤其在研究级问题建模和拒答校准上。

LLM serving 调优很难靠直觉，因为 backend、tensor parallel、prefill/decode split、worker count、scheduler、routing、KV cache、autoscaling 和 topology 会互相影响。真实 GPU 实验成本高，而且单点优化可能只是把瓶颈挪到别处。DynoSim 的价值是先在 simulation 里扫几千个配置，再把少数候选拿到真硬件验证。

这和传统系统里的 capacity planning / trace replay 很像，但 LLM serving 多了 KV cache、prefill/decode 分离和动态 batching 等特有变量。对大规模推理团队，类似 simulate-then-verify 流程会越来越必要，因为模型和请求分布变化太快，靠人工经验维护 routing 和 cache policy 很难跟上。

LightAgent 不是最大或最重的 agent framework，但它反映了开源 agent runtime 的现实需求：轻量、可嵌入、OpenAI-compatible、MCP 接入、技能组合和可观测性。v0.7.0 的 trace observability 很关键，因为只要 agent 能调用工具，开发者就需要知道每一步模型请求、工具参数、错误、重试和最终结果如何串起来。

与 LangGraph 这类 graph-first 框架不同，LightAgent 更像一个小型可组合 runtime。它适合个人项目、插件系统或轻量服务，而不是一开始就引入复杂 orchestration 平台。当前开源 agent 工具的分化正在变清楚：有的做 workflow graph，有的做安全 sandbox，有的做 tracing，有的做 skill runtime；LightAgent 选择的是低门槛 runtime + observability。

这篇不是新算法，但它给当前 agent 工程提供了一个有用框架：真正让 agent 可用的往往不是单次回答，而是围绕代码形成的可执行状态、工具接口、验证脚本、测试环境、日志、配置和协作协议。代码既是 agent 写的东西，也是 agent 运行、观察、记忆和改进自己的环境。

把它和 Codex、Claude Code、Grok Build、AX、SkillOpt 放在一起看，趋势很清楚：agent 的核心资产正在从 prompt 迁移到 harness。谁能提供更好的可执行环境、状态管理、权限边界、评测回路和 skill/tool 编排，谁就能把同一个 frontier model 用得更稳定。