在日新月异的AI浪潮中，保持前沿视野与敏锐洞察，是持续创新的核心动力。2月9日起，图灵院公众号全新栏目「算法半月报」正式上线。栏目内容源自图灵院研发一线工程师的深度沉淀，旨在为大家甄选前沿资讯、实战测评工具、分享真实思考。定期更新，干货满满，欢迎关注~
模型更新：GPT 和 Claude 头部模型开放受限；百度、Qwen 与 DeepSeek 小型更新。
产品介绍：微信“小微”开始灰度测试；Loop Engineering 设计自动运行的系统。
1、Unlimited-OCR
百度开源了 Unlimited OCR，一个基于 DeepSeek OCR 改进的端到端文档解析模型，总参数 3B、激活参数仅 570M。该模型提出 Reference Sliding Window Attention（R-SWA）机制，将解码阶段的 KV Cache 固定为常数，使单次前向传播即可连续解析数十页文档。在 OmniDocBench v1.6 基准上达到 93.92% 综合指标，位列端到端模型第一；推理速度较 DeepSeek OCR 提升 12.7%，输出长度达 6000 tokens 时速度优势扩大至 35%。Unlimited OCR 的核心能力是长程解析：输入数十页 PDF 文档图像，一次前向传播从第一页连续解析到最后一页，输出全文 Markdown 格式结构化内容，KV Cache 始终保持恒定，输出延迟不随页数增长。
2、DeepSeek-V4-Pro-DSpark
DeepSeek-V4-Pro-DSpark 并非全新架构模型，而是在 DeepSeek-V4-Pro 基础上引入了推测性解码模块。此次更新的重点在于工程落地，而非模型能力本身的迭代。DSpark 的核心初衷是解决在生产环境中（尤其是高并发场景下）LLM 推理面临的延迟和吞吐量瓶颈。推测性解码是一种在不改变模型输出分布的前提下加速大语言模型推理的技术。其核心思路是引入一个轻量级的草稿模型，预先生成若干候选 token，再由目标模型对这批候选进行批量验证和接受，从而将串行逐 token 生成转变为并行批量校验，大幅降低端到端延迟。
3、Qwen-AgentWorld-35B-A3B
Qwen-AgentWorld 是首个在单一模型中覆盖七大智能体交互领域的语言世界模型。它通过长链式推理模拟智能体环境，在给定智能体动作和交互历史的情况下预测下一个环境状态。该模型通过三阶段训练流程构建：CPT（持续预训练）注入环境知识，SFT（监督微调）激活下一状态预测推理能力，RL（强化学习）提升模拟保真度。
4、Krea-2-Turbo
Krea 团队发布并开源了 Krea 2，一个面向创意探索的基础图像生成模型系列。模型采用 12B 稠密 DiT 骨干、Qwen3-VL 文本编码器以及 Qwen Image VAE。
1、GPT-5.6
OpenAI 发布了这一新系列的限量预览版，涵盖三款定位各异的模型：旗舰级的 Sol、面向高频日常工作的 Terra，以及主打性价比的 Luna。该系列在编程、网络安全和生物学领域表现尤为突出，同时在需要持续专注的长链式智能体任务中也展现出更强的稳定性。此次发布采用受限预览形式，初期仅向少数受信任的合作伙伴和机构开放 API 及 Codex 访问权限，随后逐步推向 ChatGPT 及更广泛用户群体。
2、Claude Sonnet 5
Sonnet 5 成为所有 Free 和 Pro 用户的默认模型。相较于上一代 Sonnet 4.6，Sonnet 5 在推理、工具使用、编程和知识工作任务中，性能显著提升。API 定价方面，Anthropic 给出了限时大促：输入2美元/百万 tokens，输出10美元/百万 tokens。8月31日之后，恢复输入3美元和输出15美元的原价。相比之下，Opus 4.8 是5美元和25美元，GPT-5.5标准版是5美元和30美元。需要注意的是，Sonnet 5 采用了全新的 tokenizer，以优化文本处理性能。相同输入内容，现在会映射为更多 token，具体增幅约为 1.0～1.35 倍，视内容类型而定。
Sonnet 5 指标
从 GPT-5.6 和 Fable 5 可以看到一个明显变化：闭源模型不是简单地“发布即开放”了。一方面，模型能力越来越强，尤其是在编程、工具使用、网络安全、科学研究和长程 Agent 任务上，已经不只是回答问题，而是具备了更强的执行能力。另一方面，越强的模型越容易触及安全、合规、地区限制和监管问题，所以厂商的开放节奏也变得更加谨慎。
对普通用户来说，新模型发布并不意味着马上就能用。GPT-5.6 这类模型会先进入受限预览，优先开放给少数可信合作伙伴和机构；Claude 这类产品则对支持地区、手机号验证、支付方式和访问环境有更严格要求。对于国内用户和开发者来说，账号稳定性、支付可用性、API 可访问性和后续封控风险，已经成为使用闭源模型时必须考虑的现实问题。闭源模型未来的竞争点，很可能不只是“谁的模型更强”，而是谁能在能力、开放节奏、安全策略、开发者体验和生态稳定性之间找到更好的平衡。
截至发稿前，artificial analysis 榜单上的前十名如下：
目前 gpt-5.6 指标尚未更新
链接:https://artificialanalysis.ai/leaderboards/models
一、微信小微
我目前没有小微内测资格，所以不能算一手实测。下面主要基于腾讯客服说明和媒体实测信息做观察，具体功能仍以微信后续正式上线版本为准。获得内测资格的用户，可以在微信主界面左上角看到“小微”入口，也可以在聊天对话框、公众号、视频号等场景中唤起。
小微不是一个独立 AI 应用，而是嵌入微信内部的原生 AI 助手。它支持通过文字或语音指令操作部分微信功能，例如发送消息、拨打微信电话、设置提醒、搜索资料、总结内容等。同时，它还可以调起小程序完成一些日常服务，比如点餐、打车、订酒店、查快递等。
另一个值得关注的功能是“小工具”。在“小微”中，用户可以根据自己的需求来定制工具。
这件事的重点不只是微信也接入 AI 了，而是微信生态的入口逻辑可能发生变化。过去用户使用小程序，需要自己搜索、点击、跳转、选择服务、填写信息。现在 AI 助手有机会把这些小程序变成可调用的 Skill。用户不再需要知道具体入口在哪里，只要说出目标，AI 就负责理解需求、匹配服务、调用小程序并完成中间步骤。这和 Agent 的发展方向非常一致：AI 不只是回答问题，而是开始操作已有工具和服务。
当然，小微仍处于灰度测试阶段，能做到什么程度还需要继续观察。尤其是涉及隐私、聊天记录、支付、转账、授权、误操作等场景，微信必须非常谨慎。但从产品方向看，小微的意义非常大。它代表超级 App 正在尝试从“功能集合”升级为“智能操作系统”。微信原本连接的是人、内容和服务；如果小微成熟，未来它连接的可能就是“用户意图”和“微信生态里的各种能力”。
二、Loop Engineering
简介
Loop Engineering 是一种把人从反复 prompt Agent 中抽离出来，转而设计一个能自动发现任务、调用 Agent、验证结果、保存状态并持续进入下一轮的自运转系统的方法。Loop Engineering 的核心不是“怎么写更好的提示词”，而是“怎么设计一个系统，让它自动替你去提示 Agent，并反复运行”。
以前的流程是：人写 prompt，Agent 执行，人看结果，人继续补充 prompt。
现在的思路是：人设计 loop，loop 自动发现任务、调用 Agent、检查结果、保存状态，并进入下一轮。
这背后其实是 AI 使用方式的一次变化。
Prompt Engineering 关注的是：我怎么把一句话说清楚，让模型这一次回答得更好。
Context Engineering 关注的是：这次任务该给模型哪些上下文，不该给哪些上下文。
Harness Engineering 关注的是：单次 Agent 运行时，应该配置哪些工具、权限、文件、测试和完成条件。
Loop Engineering 关注的是：怎样搭建一个能持续运转的系统，让 Agent 不只是被动执行一次任务，而是能够反复发现问题、处理问题、验证结果并继续下一轮。
简单来说，Prompt Engineering 是“我怎么跟 Agent 说”。Loop Engineering 是“我怎么造一个系统，让它自己不断跟 Agent 说”。
Loop Engineering 出现的基础有三个：
第一，Coding Agent 已经能完成非平凡任务。过去 Agent 跑几步就容易崩，现在 Claude Code、Codex、OpenClaw、Hermes 这类工具已经能在代码库里完成真实任务。
第二，Harness 已经成熟。也就是 Agent 已经有了工具调用、文件读写、Git 操作、浏览器、测试执行、MCP 连接器等能力。单次运行已经能“武装起来”。
第三，运行成本下降。一次 Agent 调用不再非常昂贵，反复跑、定时跑、多 Agent 并行跑开始变得可接受。
所以，当“Agent 能干活 + 工具能接入 + 成本能承受 + 定时/自动化能力存在”以后，自然就会出现一个新问题：既然 Agent 能做事，为什么还要我每天手动启动它、手动告诉它下一步干什么？Loop Engineering 就是对这个问题的回答。
1. Discovery：自动发现这轮该做什么
Loop 的第一步不是人每天告诉 Agent：“今天你修这三个 bug。”而是系统自己去读 CI 失败记录、open issues、最近 commit、用户反馈、日志告警、待办队列等信息，然后判断哪些任务值得处理，哪些只是噪声，哪些已经有人处理，哪些优先级更高。
Discovery 的本质是把“任务发现”自动化。
2. Handoff：把任务交给 Agent，并做好隔离
发现任务之后，要把任务交给执行 Agent。这里的关键是隔离。在代码场景中，通常可以用 Git worktree 或临时分支，让多个 Agent 并行工作，避免互相覆盖文件、污染主分支或打乱上下文。
Handoff 的本质是把“任务交接”和“执行环境准备”标准化。
3. Verification：让另一个 Agent 或确定性规则说“不”
这是最重要的部分。Loop 最大的问题不是让 Agent 运行，而是让系统里有一个能说“不”的东西。很多人做 Agent 系统时，最容易犯的错误是：Agent 写完 → Agent自己检查 → Agent 自己说没问题。这就是 Nodding Loop，可以理解为“点头循环”。也就是 Agent 一直在自我认可：我检查过了、可以通过、继续下一步。问题在于，生成者不适合评价自己。因为它在生成时已经形成了一套“为什么我要这样做”的内部理由，再让它检查，它很容易继续沿用这套理由。
所以应该主张 Generator / Evaluator 分离：
Generator：负责生成、修改、执行
Evaluator：负责挑错、质疑、验证
Evaluator 要具备几个特点：不同提示词、最好不同模型、默认怀疑、不要表扬、必须执行测试或真实操作、只在证据充分时 PASS、否则 REJECT 并列出原因。
4. Persistence：把状态写到上下文窗口之外
Agent 的上下文窗口不是长期记忆。如果一个 loop 只把结果留在聊天记录里，那么下一轮清空上下文后，系统就忘了昨天做了什么、哪个任务完成了、哪个任务失败了、哪个任务需要人工处理。所以需要强调：The agent forgets, the repo does not. 可以理解为：模型会忘，磁盘不会忘。因此 loop 必须把状态写到外部，如：Markdown 文件、数据库、任务队列等。
Persistence 的本质是让系统状态脱离模型上下文，变成可追踪、可审计、可恢复的工程资产。
5. Scheduling：让它自己再次运行
最后一步是调度。没有调度，系统只是一个“可以手动运行的 Agent 脚本”。有了调度，它才变成真正的 loop。调度方式可以有很多种：本地 cron、launchd、Windows Task Scheduler，CI 定时任务，云函数，队列 worker，Slack 或飞书事件触发，GitHub issue 触发，文件上传触发，甚至 Agent 工具自身内置的循环能力。
Scheduling 的本质是让系统从“一次性执行”变成“持续性运行”。
Loop 的四种隐性成本
1. Verification debt：验证债
Loop 产出越多，未验证内容越多。例如：一晚上开了 20 个 PR，测试都是绿的。但其中 3 个有测试没覆盖的问题，如果没人发现，这些错误就会进入系统。
解决方式：独立 Evaluator，确定性测试，抽样人工 review，关键任务必须人工确认。
2. Comprehension rot：理解腐烂
Loop 写了很多代码或文档，但人没有读。结果是：系统变了，代码库变了，知识库变了，但人的脑中地图没有更新。这会导致后续出问题时，没人真正理解系统。
解决方式：每天抽样读 loop 输出，要求自己能解释它改了什么、为什么这么改。如果解释不了，说明人的理解已经落后于系统变化。
3. Cognitive surrender：认知投降
这是更危险的一种状态。当人开始觉得“反正 Agent 会做，看起来没问题我就点通过”，人就从工程师变成了“按通过按钮的人”。
解决方式：保留人工 checkpoint，明确哪些决策不能自动化，人必须保留否决权。
核心观点：Loop 可以执行，但不能决定。
4. Token blowout：Token 爆炸
Loop 会反复运行，不断 retry，派生多个 sub-agent，保留大量上下文，一晚上空转。如果没有预算上限，可能费用突然暴涨。
解决方式：设置单次 token 上限，每日预算上限，最大 retry 次数，最大并发数，最大运行时长，失败熔断，异常报警。
这期内容里，我更关注的是 AI 使用方式正在发生变化。过去我们更多是在“选模型”：哪个模型更聪明，哪个模型写代码更强，哪个模型便宜，哪个模型上下文更长。但现在，真正影响落地效果的，已经不只是模型本身，而是模型能不能稳定接入、能不能持续运行、能不能被验证、能不能控制成本，以及出问题后能不能追踪和回滚。这也是为什么我觉得 Agent 的下一阶段不是简单地“更自主”，而是“更工程化”。
一个真正可用的 Agent 系统，不能只是模型自己说自己完成了任务。它需要有任务发现机制，需要有工具和权限边界，需要有独立验证，需要把状态写到模型上下文之外，也需要有预算、并发、重试和失败熔断。否则，所谓自动化很容易变成自动制造问题。
对于开发者和企业来说，接下来做 AI 应用也要调整思路。第一，不要只依赖单一闭源模型。模型发布节奏、地区限制、账号风控、API 可用性都会影响真实业务，系统架构上要提前考虑多模型切换和降级方案。第二，不要只追求“模型能不能做”。更重要的是，它做完之后谁来验、错了怎么办、状态存在哪里、成本有没有上限。第三，不要把 Agent 当成一个聊天入口，而要把它当成一个可以持续运行的工程系统。聊天只是交互方式，真正有价值的是任务流、工具链、验证链和状态管理。
未来 AI 应用的分水岭，可能不在于谁接入了最新模型，而在于谁能把模型能力变成一个可靠、可控、可持续运行的系统。模型会越来越强，但工程约束也会越来越重要。AI 可以执行，但系统必须可控；Agent 可以自动跑，但人必须保留判断权。
更多内容，敬请期待
注：本文仅用于技术探讨、科普学习，不含商业用途，内容观点仅供参考。