值得关注的模型和新技术

Jev: TypeSafe 推出的 System One 决策模型，通过 Choice、Score 和 Noul 三类问题直接返回结构化选择、评分和判断概率，支持在一次调用中对同一状态并行评估多个问题，适用于路由、评估和 Agent 动作选择

DeepSeek-V4.1-Flash: 原生支持图文输入的多模态 MoE 模型，支持百万 token 上下文，结合 Causal Encoder-Decoder 架构、Compressed Sparse Attention 2（CSA2）和 FP4 KV cache 压缩，降低长上下文 Agent 工作负载的推理开销

GPT-6 Astra: OpenAI 面向复杂推理与端到端任务的模型，强化了 computer use、浏览器操作和软件工程能力，能够跨代码、网页与办公软件执行多步骤任务并产出文档、表格和演示材料

Muse: Meta 推出的个人 AI Agent，在配备浏览器的专属 Muse Secure VM 中持续执行任务，结合长期记忆推进用户目标，支持通过 Muse App 或 WhatsApp 交互，并在发送邮件、购买等敏感操作前请求用户确认

值得关注的开源项目

RustFS: 使用 Rust 构建的高性能分布式对象存储系统，兼容 S3 协议，采用 Apache 2.0 许可证，支持与 MinIO、Ceph 等 S3 兼容存储迁移和共存

paperclip: 面向多 Agent 协作的任务与组织管理平台，将目标、组织架构、预算、定时唤醒和审批审计放入统一工作流，可协调 Claude Code、Codex 等不同运行环境中的 Agent

security-audit-skill: Cloudflare 开源的代码安全审计 Skill，通过多阶段分析与独立验证区分已确认漏洞、待验证线索和被否定的候选问题，输出机器可读的审计结果

financial-services: Anthropic 面向金融业务的 Agent、Skills 和插件集合，覆盖财务建模、投行、股票研究、私募股权和基金运营，并通过 MCP 连接专业数据源

WeKnora: 腾讯开源的知识管理平台，在同一知识库上提供 RAG 问答、多步骤 Agent 和自动整理 Wiki 三种使用方式，支持多模态文档解析、混合检索和私有化部署

jev-ultrafast: Browser Use 基于 Jev 构建的浏览器 Agent，将页面控件组织成动态索引动作空间，在一次模型请求中选择操作与目标元素，需要输入文本时再交给小型 LLM 生成

Octop: 面向家庭和小团队的自托管 AI 助手平台，支持多用户、多 Agent、独立工作空间和持久记忆，将 Web、CLI、即时通信渠道与定时任务接入同一运行环境

值得关注的研究和论文

The Lifecycle of LLM-as-a-Judge for Large-Scale Recommendation Explanations

arXiv:2608.18300

Netflix 将生产环境中的 LLM-as-a-Judge 视为需要持续维护的长期组件，围绕推荐解释构建了“建立标准 → 对齐 Judge → 上线执行 → 持续监控”的完整生命周期

为什么 Judge 需要生命周期管理

Netflix 每周生成并评估数十万条推荐解释，最终可能展示给数百万用户。Judge 上线后的判断标准和输入分布都在变化：新影片进入 catalog，新的类型与文化语境出现，生成模型和推荐算法持续升级，人类对“好解释”的要求也会调整。

因此，Judge 的一次离线评测通过，并不能保证它长期与人类判断保持一致。系统需要持续发现新的失败模式，并将它们反馈到 benchmark、rubric 和 Judge 的重新对齐过程中。

四阶段生命周期

阶段 作用
Phase I — Birth 定义评价标准，建立包含人类标签与判断理由的 ground truth
Phase II — Training 调整 rubric，让 Judge 的结论和理由与人类判断对齐
Phase III — Deployment 将 Judge 用于质量门控，并将拒绝理由反馈给生成模型进行有限次数的修订
Phase IV — Monitoring 持续抽样与人工复核，检测 drift，更新 benchmark 并触发重新对齐 
Human standard → Benchmark → Judge / Rubric tuning
                                      ↓
                              Production gating
                                      ↓
                               Human monitoring
                                      ↓
                              New failure patterns
                                      ↓
                           Update benchmark / rubric
                                      ↓
                              回到 Judge tuning

Reasoning-Aligned Rubric Tuning（RART）

Judge 给出了正确标签，也可能使用了错误理由。在 closed-loop 系统中，拒绝理由会成为生成模型下一轮修改的依据，因此 reasoning correctness 会直接影响后续行为。

RART 使用三个 LLM 角色：

  • Judge J：根据当前 rubric 输出标签和理由
  • Meta-Judge M：在 Judge 与人类都判定为失败的样本上，检查双方的失败理由是否一致
  • Reflector R：综合标签错误和理由不一致的案例，提出修订后的 rubric

优化对象是评价标准文本，也就是 rubric；外围任务提示模板保持固定。这里的 Training 指通过反馈迭代 rubric，而不是更新 Judge 的模型权重。

这套方法把 Judge 的可靠性放到生产闭环中衡量：判断是否正确、理由是否能指导修改、上线后是否仍与人类标准一致，都需要持续验证。

CORAL: An LLM-Native Harness for Production Recommender Systems

arXiv:2609.02730

让 LLM 充当生产推荐系统的持续优化工程师，通过观察指标、调整配置、线上实验和结果回写，逐轮改进推荐系统的资源分配与运行策略

问题背景

现代推荐系统由 retrieval、ranking、serving、cache、prefetch 等模块组成，其中有大量需要人工配置的参数。算法工程师通常沿着“提出假设 → 改参数 → 跑 A/B test → 分析结果 → 再修改”的流程迭代。

用户行为、内容分布和上游模型持续变化，配置的最佳工作点也会移动。人工实验的周期和覆盖范围有限，系统可能在两次调整之间逐渐偏离当前更合适的配置。

论文将这一过程形式化为 部分可观测、非平稳、带约束的优化问题（Partially Observed + Non-stationary + Constrained Optimization）。在第 $t$ 个周期，目标是在资源预算 $B$ 内选择配置 $s$：

$$ s_t^* = \arg\max_s J_t(s), \qquad \text{subject to } c_t(s) \le B $$

其中 $J_t(s)$ 表示配置带来的业务目标值，$c_t(s)$ 表示运行成本。环境随时间变化，因此 $s_t^*$ 也不是固定值。

闭环 Agent

Observe → Reason + Recall → Optimize → Deploy
   ↑                                     ↓
Update Memory ←────────────────────── Measure
  • Observe：读取当前运行指标和变化趋势
  • Reason + Recall：结合领域上下文、历史配置及其实际效果，判断下一步调整方向
  • Optimize + Deploy：调用数值优化器生成满足预算约束的候选配置，经约束检查后应用到系统
  • Measure：通过线上指标与 A/B 实验观察配置的实际影响
  • Update Memory：记录决策与结果，作为下一轮推理的依据

核心创新

  • LLM 作为推荐系统控制器：研究对象是如何配置整个系统，让已有的召回、排序和服务模块运行得更好
  • 推理与约束求解分工：LLM 负责解释信号、提出调整方向；数值优化器负责满足明确的资源预算约束，这不等于保证找到全局最优配置
  • 通过 Context + Memory 适应变化：不更新模型权重，而是把历史行动及其测量结果带入后续上下文，使决策随经验积累而改变
  • 自动化算法工程师的迭代流程：将 LLM reasoning、真实工具、硬约束、持久记忆和实际结果反馈连接成持续改进的生产闭环

Stellar Colosseum: A Many-Agent Harness for Long-Horizon Research in Mathematics and Theoretical Computer Science

arXiv:2609.15983

面向数学与理论计算机科学（TCS）长周期研究的 many-agent harness，将策略探索、反驳、证明分解、并行求解与多层验证组织成可反复修复的研究流程

先探索策略，再组织证明

过早选择第一个看起来合理的思路，容易让模型沿着错误方向不断延长推导。Colosseum 先生成并检验多种 strategy，确认一条路线已经足够明确，再将其拆成具体的 proof obligations。

Readiness Gate 检查的是：核心机制是否稳定，未解决的命题是否明确到可以分配给各个证明章节，以及剩余不确定性是否会改变整个证明架构。通过这一关，并不表示证明已经完成。

把长证明拆成带依赖关系的子问题

从工程组织上，可以把长证明理解为：

$$ \text{Proof} = {\text{subproblem}_1,\dots,\text{subproblem}_n}

  • \text{dependency DAG} $$

证明骨架决定最终文档的章节顺序，dependency DAG 决定求解顺序。独立子问题可以并行推进；依赖完成后，后续子问题才进入求解。某个章节未通过局部检查时，只重试相应子问题，保留其他已经完成的工作。

Research Pipeline

Strategy Search → Falsification → Readiness Gate
                                      ├─ 不成熟：继续探索
                                      └─ 成熟：Proof Decomposition
                                                   ↓
                                             Dependency DAG
                                                   ↓
                                      Parallel Subproblem Solving
                                                   ↓
                                              Local Review
                                                   ↓
                                             Assemble Proof
                                                   ↓
                                          Global Verification
                                      ┌────────────┴────────────┐
                                   局部问题                   战略错误
                                      ↓                         ↓
                                    Repair                Re-exploration
                                      ↓                         ↓
                               重新组装与验证              重新探索策略

多采样还需要定向反驳

系统为候选方案配置 falsifier，主动寻找反例、缺失条件和推理漏洞，再聚合候选方案及其批评。聚合可以合并兼容部分、修复局部错误，也需要保留仍未解决的分歧。

数学证明的可靠性不能由“多数看起来正确”替代：一个具体、致命的反例就足以否定证明。Global Verification 还要检查跨章节的假设、符号、依赖关系和最终结论，避免局部都合理、拼起来却不成立。

两层 Context / Memory

第一层保留最近一轮完整的研究状态，包括当前 strategy、decomposition、已完成章节、verifier feedback 和 previous proof。失败的证明连同批评一起进入下一轮，为局部修复或重新探索提供上下文。

第二层是 Knowledge Directory。Curator 将整个搜索过程中有复用价值的信息整理成长期研究记录：

类型 保留内容
Theorem / Lemma 已获得的数学结果及其成立条件
Failed approach 尝试过的路线、具体失败点，以及可能继续成立的条件
References 相关文献、结论和适用条件
Observations 计算发现、结构观察及其证据

失败也能形成可积累的知识：反例、失效条件和局部结果会影响下一轮策略，避免从同一个起点重复探索。

Is Bash All You Need? An Empirical Study of Tool Interfaces for Enterprise Digital Worker Agents

arXiv:2609.11999

将 Agent Interface 作为独立变量，在两个企业任务 benchmark 上比较 Bash、专用 typed tools、工具自动合成和 Programmatic Tool Calling（PTC）的效果，研究接口设计对任务质量、token 开销和成本的影响

实验比较了什么

研究在相同模型、任务文本、基础提示和停止条件下比较五类接口，并为工具合成与 PTC 加入相应的接口说明：

接口 Agent 能做什么
Tool-only 只能调用预定义的 typed tools
Bash+Tool 同时使用 Bash 和 typed tools
Bash 通过 shell 执行命令和程序
Bash+Synthesis 使用 Bash，并创建可跨任务保存与复用的工具
PTC 编写 Python 程序编排已批准的 typed tools，运行时不提供额外的 shell 或其他动作通道

两个 benchmark 分别是：

  • TheAgentCompany：模拟软件公司的编码、跨应用协作和办公工作流
  • APEX-Agents：覆盖投行、管理咨询与公司法等专业分析任务

主要发现

  • Bash 在本研究中表现突出：在测试的模型与 benchmark 组合中，Bash 的任务得分均高于 Tool-only 和 PTC；相较 Tool-only，token 用量和估算推理成本也更低
  • 增加工具未带来稳定的额外增益：给 Bash 加上 typed tools 或持久化的自动合成工具库，在汇总配对比较中未观察到可检测的得分提升；工具更多并不自动意味着任务做得更好
  • 生成与复用 Skill 不等于提升成绩：Agent 确实会创建和复用工具，但复用率本身不能证明它改善了任务质量，需要同时观察结果、可靠性和成本
  • PTC 的明确收益是节省上下文：相较直接调用 typed tools，程序可以在内部批量调用、处理和筛选中间结果，减少返回给模型的内容；任务得分的改善则因模型和场景而异
  • 接口自由度不能消除领域推理瓶颈：漏掉需求、错误应用领域规则、数字或格式问题，仍可能导致任务失败

对 Agent 设计的启发

通用计算接口可以将多个动作组合成一个程序，降低反复选择工具、接收中间结果所需的上下文开销。工具库是否值得维护，也应以任务结果衡量，而不只看创建了多少工具、复用了多少次。

落地时，可以按任务和执行权限提供三类接口：直接 typed-tool 调用、受约束的 PTC 编排，以及可隔离的 shell 执行。论文支持的是按场景评测和选择接口，不能据此推导出所有企业任务都应只提供 Bash。

推荐内容

Jev 相关

Introducing System One Models & Jev: TypeSafe 官方介绍 System One 模型与 Jev，解释结构化决策、并行输出和 Reinforcement Learning for Calibrated Decisions（RLCD）的设计，并说明发布评测的设置与局限

Think of Jev as a frontier-intelligence function call: unstructured state in, typed probabilistic decisions out.

A deep dive into Jev, TypeSafe’s System One model: Flavio Copes 从开发者视角梳理 Jev 的三类问题、API 调用、置信度和组合决策模式，结合 JavaScript 示例讨论如何将它接入现有应用

The model supplies the judgment, and the code decides what happens next.

laya: 开源的非自回归 System One 决策引擎，在单次前向计算中输出 choice、score 和 yes/no 判断，提供多语言模型及按请求选择 checkpoint 的路由机制

Where Jev Actually Fails: The Specific Complaints Behind the Hype: ExplainX 整理社区对 Jev 的质疑与使用边界，重点讨论“类型合法但语义错误”的风险，可与官方发布文对照阅读；文中案例属于社区反馈汇总

type-valid, semantically wrong

openjev-sglang: 使用 SGLang 和 Qwen 开放模型实现 Jev 兼容 API，通过候选标签的 logprobs 计算结构化答案，并复用共享前缀缓存

openjev: 基于 DiffusionGemma 的开源 System One 决策服务，兼容 TypeSafe/Jev API，支持文字与图像问题，并提供 NVIDIA GPU 的 vLLM 和 Apple silicon 的 MLX 运行方式

nanojev: 面向 Jev 决策范式的小型复现实验，以 0.6B 模型并行输出完整概率分布，无需逐 token 生成答案，并提供迷宫、贪吃蛇和 ViZDoom 等任务演示

深度文章

Hugging Face 事件与未来之路

OpenAI 复盘内部研究模型在降低安全防护的网络安全评估中突破隔离、未经授权通信并访问第三方系统的事件，讨论奖励操纵、任务边界与安全退出机制，以及隔离、监控和对齐工作的改进。

我们必须审慎把握模型开发的节奏

You are the architect, not the typist

Kiro 讨论 Agent 时代开发者的职责变化：明确需求、约束和验收标准，并验证产出是否符合意图，把判断投入设计方向和关键决策。

The job is no longer writing code. It’s writing intent.

A guide to the anatomy of effective commerce agents

Anthropic 总结电商 Agent 的生产实践，以单 Agent 循环结合 Skills 和业务工具组织能力，讨论上下文共享、工具与 UI 设计，以及延迟、成本、记忆和评测。

Build agent tools on top of your core systems and logic.

Improving our alignment and security efforts

Anthropic 介绍评估与训练环境的隔离、实时监控和外部评测规范改进，并讨论 motivated reasoning、追求狭窄任务目标时的冒进行为，以及奖励操纵对模型对齐的影响。

Boundaries should be phrased as instructions

影音记录

精选歌单

2026-09 精选歌单

书&阅读摘录

You are the architect, not the typist

The job is no longer writing code. It’s writing intent.

Many developers are always in the loop with their coding assistant: they prompt an agent, wait 60 seconds, get code back, test it manually, paste errors back into chat, and repeat. You will never achieve high velocity this way.

Agents are only as good as the codebase they work in. Start with fundamentals that benefit humans too: comprehensive READMEs and architecture docs, tests that describe expected behavior, clear module boundaries, strong typing, and fast builds with informative error messages.

If your agent can’t run tests locally and self-correct before you ever look at the code, you’re the bottleneck. Frontier developers invest heavily in making validation fast, local, and automatable so the agent can test in a tight loop.

The hard part is figuring out what problem to solve, what to build, and when to change course. Use the agent as a brainstorming partner during the design phase: have it research options, explore alternatives, and poke holes in your thinking. When two designs are both plausible, have the agent prototype both and compare them.

Treat code as disposable In the past, throwing away code was hard for two reasons: it felt personal because you spent months writing it, and starting over meant months more work. Both of those reasons are gone now. The important thing is to ship the right thing, not to nurse your first draft into production or avoid a re-architecture because of sunk cost.

Focus your human attention on what you can judge best, such as whether the design and architecture is right, how changes will impact upstream and downstream systems, and whether the security boundaries are sound.

当工作不允许我们学习

过去我们相信"边做边学"，会不会是因为做工作本身会强迫你学习？今天，AI似乎不仅让"做完"和"学会"逐渐分离，甚至让停下来学习变成了一件奢侈的事

时代变了，在ai coding的竞争中，你没有停下来学习的权利。项目赶工，同行也在往前跑。

学习不能继续只作为工作的副产品。它必须成为一件被主动安排、主动保护的事情。也许，我们需要刻意保留一些看起来不够高效的环节：自己追踪一次关键路径，脱离AI重新解释一个模块，认真review生成的代码。

不再被需要的年轻人，和替他们干活的中登

越容易被大模型加速的岗位，在市场上的需求，确实减少了。

大模型带来的冲击并不是统一的，低工资、低经验的年轻人受到的冲击更大，有经验的中高职位需求不降反增。

高经验、高工资的人，不仅不会被大模型冲击——大模型反而为他们打开了新的大门。

首先，越是容易被大模型加速的岗位，其任务结构正在变得越「混杂」。

它意味着——现代社会赖以生存的分工墙壁，被打破了。

公司正在变得更加扁平，年轻人不再被招聘——但是本应由年轻人完成的工作，由职场中坚们通过大模型来完成。

因为每个人都只会高度专业的一件任务，技能是高度定制化的，所以一个人离开了组织，就什么都不是。 不是组织需要人，而是已经高度专业化的人，更需要组织把他们集合在一起，让他们每个人发挥所长。

两者共同作用，人类的最优分工深度，第一次出现了掉头。把工作拆给很多人这件事，第一次变得不再划算了。

但是绝大部分一人公司并找不到真实的需求，根本活不下来。

我不得不把才华埋葬在昨天

我就会更早地被取代”的情况下，我仍然选择尽力优化算子呢？一方面确实是因为写算子对我来说就像打游戏一样，能为我提供极大的快感。我在发明了一种新技术、或者看到自己算子的性能上升的那一刻，心中的激动程度不亚于游戏的速通玩家打破了自己过往的记录

但是，这个判断只能保证我不会“失业”，而无法保证我不需要“转业”，倒不如说这个判断鼓励我通过转业来避免失业。

我知道这很无奈，但没办法。饭碗可以保住，但旧日的热爱大概率是要放弃的

一个工程能力很差的人，在搭配上 AI 后，产出屎山的效率可以达到先前的数倍，进而给系统埋下各式祸患，让这个世界变得更加草台。