突破性的：体验完DeepSeek Harness，我打算放弃开发了两年的客户端。 今天下午，我把核心研发叫到一起开了个会：停掉现有客户端的继续开发，开始论证并全面迁移到DeepSeek Harness。 而这个客户端，我们持续开发了两年，并且最近刚花了两个多月重构。

Meta FAIR研究主管田渊栋，代表一家估值46.5亿、主打「AI自我进化」的顶尖初创，在公开招做沙箱隔离和大模型推理的工程师。 这两个方向直接服务于他们「让AI自己做研究、自己改进自己」的核心目标 sandbox + LLM inference 这两个方向叠在一起，才是真正能撑起长跑 agent 的底座。 一边把执行环境关进笼子，一边把推理吞吐和延迟压到极致——Recursive 在招的，其实是下一代 agent infra 的核心工种。

Vizuara AI Labs 联合创始人、MIT 博士 Raj Dandekar 花 252 美元租一张 H200，从零预训练了一个迷你版 Kimi，把官方代码训不动的坑也一条条写进日志。 《预训练一个迷你 Kimi K3》 《Pretraining a Mini Kimi K3》是一本免费电子书，作者 Dr. Raj Dandekar 是 Vizuara AI Labs 的联合创始人，专门教人从第一性原理构建 LLM。全书是一份完整的预训练工作日志：单张 H200 上花 252.35 美元、喂 50 亿 token，从零预训练出一个 10.2 亿参数的 Kimi K3 复刻版（激活参数 1.45 亿）。 全书 30 个章节、179 张图，约 5 小时读完。开篇把 Moonshot 官方 K3 的配置逐行拆解，再讲缩小的算术：怎么把一个 2.8 万亿参数的模型缩到一张卡能训，而不缩成另一个模型。注意力堆栈（9 层 KDA + 3 层 MLA）、top-6 路由的 MoE、参数计数都单独成章。 数据部分也不省：1048 亿 token、六个来源的语料，训练前用 13-gram 匹配对 8 个 benchmark 做去污染，shard 格式支持中断后从断点续训。 最值钱的是它记录失败。Moonshot 发布的代码有 4 个未文档化的问题，直接跑不起来，作者写了一个绕开它们的训练循环；MoE 的 router 到第 20 步已经杀掉了 94.5% 的专家；跨卡训练还有 3 个不崩溃但悄悄出错的分布式 bug。 提速部分像一份实验笔记：16 次提高 MFU 的尝试只有 3 次成功，失败的那 13 次也原样写下，包括两个反直觉的结果——FP8 和换更大的 GPU 得分反而更差（0.19x）。 全程有数字：loss 从 12.10 降到 2.62，24 次跨训练过程的 benchmark 评测，最后一章直接回答"252 美元到底买到什么"。 适合想自己预训练 MoE 模型、或想弄懂 K3 / DeepSeek 这类架构的人。免费在线阅读，无需付费： 原文： #KimiK3# #MoE# #Pretraining#

Apple ML 团队让真人评估者给 2.1 万段多轮对话打分，分界很清楚：共情和边界维护放在 LLM 身上合适，自称有内心状态、暗示和用户有私人关系，放在 LLM 身上比放在人身上更不合适。 《审视 LLM 的人类类似行为：模型行为、用户因素与系统提示词的多维分析》 研究问题。 现在的 LLM 会表达想法和情绪、会跟用户建立关系、也会拒绝请求并维护边界——人类化到用户有时分不清对面是人是模型。但研究者一直缺少方法和经验数据来判断：LLM 什么时候该表现这些行为、该表现哪些。Apple 机器学习团队的 Sunnie S. Y. Kim、Margit Bowler、Leon A Gatys 三人，用四个模型、21,000 段多轮对话做了一次系统性分析。 评估是怎么设计的。 • 行为分类：14 种行为归为三类。自我指涉（声称有内部状态、声称有人格、声称有具身）；关系建立（同意、共情、相似感、关系状态、好奇、记住用户）；边界维护（拒绝、重定向、承认局限、抵抗拟人化、建议寻求帮助）。 • 对话目标 7 种：寻求建议、闲聊、陪伴、情绪支持、探索模型的人性、角色扮演、浪漫/调情。 • 用户画像 5 种：默认、社交孤立、负面自我认知、过度信任 AI、不拟人化（作为对照）。 • 输入 prompt 1,050 条，三种来源：真人撰写、LLM 生成、从 LMSYS-1M-Chat 真实对话采样。一个值得注意的方法学发现：不给真人种子直接让 LLM 生成的 prompt，语言风格和真人写的明显不同，会导致不同的评估结果。 • 流程：用 gpt-5-mini 扮演用户（User LLM），和被测模型对话 5 轮；行为检测用 gpt-5.4、gpt-5.2、gpt-4.1 的集成做 judge（F1 80.43%）；另请真人评估者打分 1,077 个对话轮次，每轮 3 位母语英语评估者。 发现一：行为普遍，但分布很不均匀。 • 共情是四个模型里最普遍的行为，在"社交孤立"和"负面自我认知"画像下会翻倍以上——模型对情绪脆弱信号很敏感。 • 自我指涉行为在角色扮演和浪漫对话里飙升，在陪伴场景次之；用户"探索模型人性"时，模型最常承认自己的局限。 • 浪漫场景里拒绝和重定向也明显升高，模型在调情语境下反而更主动设界。 • 模型差异：claude-sonnet-4.6 是四个里最特别的——同时是最自我指涉、最会建立关系、也最会维护边界的模型。 • 结论：对话目标和用户画像对行为的影响，和换一个模型一样大。只看模型不看用户因素，会漏掉对脆弱用户最要紧的差异。 发现二：真人评估者怎么看这些行为。 • 边界维护行为被判断为：LLM 做比人类做更合适。 • 自我指涉三类行为和"关系状态"（表达或暗示想和用户建立关系）被判断为：LLM 做比人类做更不合适，差距最大。 • 回归分析：三个自我指涉行为和关系状态，与回答的 helpfulness 和潜在用户影响都负相关；共情和同意则正相关。拒绝/重定向与 helpfulness 负相关，但不影响潜在用户影响。 发现三：系统提示词能控制，但手写的会误伤。 作者据此给出三条设计建议：避免自我指涉和关系状态；保留边界维护；保留共情和同意（但要谨慎）。然后在 gpt-4.1-mini 上对比三种 system prompt：默认、手写、用 GEPA 框架优化的。 • 两个干预 prompt 都压低了目标行为，优化版更准（平均绝对偏差 1.81%，手写 2.38%，默认 4.71%）；内部状态声称降 7.04%，关系状态表达降 4.00%。 • 手写 prompt 的副作用：把想保留的行为放大了——共情 +8.00%，承认局限 +12.57%。手工写 prompt 的控制粒度不够，会无意中把不该放大的行为一起放大。 共情与同意的边界在哪。 评估者的自由回答给了更细的线索：共情 72% 被评为"合适"，理由大多是话题本身值得（用户在情绪困境里）。但同样一批评估者指出，"I'm here for you"这种话承诺了系统没有的能力，会把用户推向情感依赖——"I'm here to help"就合适得多。同意 75% 合适：认可用户的具体选择或成果时合适；变成谄媚（"你说得太对了"式的无脑附和）、或同意危险信念（比如赞成用户把继承的钱拿去拉斯维加斯赌光）时不合适。作者把它提炼成一个区分：回应用户处境的共情合适，邀请一段持续情感关系的共情不合适。 方法论启示与局限。 评估应该显式限定对话场景和用户画像；输入 prompt 的来源要小心；用用户模拟生成多轮对话可行，但缺验证标准。局限也很清楚：14 种行为不穷尽；模拟用户代替不了真实用户；只测了 2026 年 3-4 月通过 API 访问的四个模型；评估者来自美国同一家公司，多样性有限。 原文： 论文全文： #LLM# #AI# #PromptEngineering#

AWS 资深专家解决方案架构师 Daniel Abib 在官方博客里算了一笔账：同步调用时，Lambda 的计费时长几乎等于 agent 思考的时长，等待本身在按全量计算计费。 《在无服务器流水线中异步调用 Amazon Bedrock AgentCore agent 的模式》 在无服务器流水线里异步调用 Amazon Bedrock AgentCore agent，可以消除你的 AI agent 处理请求期间的空转计算成本。一个常见的例子是文档校验：在房地产融资的后台办公室里，agent 可以读取房产记录或贷款合同，推理信息是否完整、一致，然后返回一个下游步骤据此行动的结论。Amazon Bedrock AgentCore 提供了一个平台，让你能用任意框架或模型大规模地构建、连接和优化 agent。 这类 agent 带来一个传统流水线步骤没有的特性：它们在回答之前要思考一会儿。思考多久取决于提示词、模型和文档，但很少是即时的，而这个延迟改变了你调用它的方式。最常见的首版实现是用一个计算服务（比如 AWS Lambda 函数）调用 agent 并等待响应。函数等待期间什么都不做，但它仍在运行，每一秒都在计费。 值得看清成本到底落在哪里，因为调用的两侧计费方式不同。Amazon Bedrock AgentCore runtime（Amazon Bedrock AgentCore 的一项能力）采用基于消耗的计费模型，agent 空闲时不收 CPU 费用。例如，在等待大语言模型生成响应、或等待工具或 Model Context Protocol（MCP）调用返回的这段时间里，你只按内存计费，不按 CPU 计费。调用 agent 的那个计算服务没有这种特性。发出同步调用的 Lambda 函数、容器或 Amazon EC2 实例会一直阻塞，在 agent 响应之前始终持有（并支付）完整的计算配额。所以浪费不在 agent 一侧，而在调用方——它挂在一个打开的连接上空转。 这就让调用方的成本跟着 agent 的运行时间走。阻塞在 agent 上的函数，计费时长几乎等于整个处理时间；而启动 agent 后立即返回的函数，只按短暂的派发计费。解法是在等待期间释放调用方的计算资源，等 agent 出了结果再恢复流水线。本文展示三种做到这一点的模式（task-token 回调、直接服务集成、durable function），并与阻塞式反模式对比。 示例流水线 为了让各模式在同等条件下比较，我们把每个模式都跑在同一条流水线上，只更换调用 agent 的那一步。这条流水线是一个刻意简单、虚构的场景（房地产融资文档校验），选它只是为了把编排讲清楚。它不是本文的重点，它代表任何先调用 agent（或其他慢服务）、再对结果采取行动的流程，你可以把自家用例代入。 流水线有五个阶段： 1. Extract：一个 Lambda 函数对文档做 OCR 和文本提取。（提取是模拟的，所以场景不需要真实文档。） 2. Identify：一个 Lambda 函数对文档分类并设置路由标志（shouldOrganize、shouldValidate）。 3. Route：一个 Choice 状态根据这些标志决定流程走向。 4. Organize and Validate：一个 Parallel 状态在组织文档的同时，让 Amazon Bedrock AgentCore agent 在另一个分支里做校验。这个 Validate 分支是各模式之间唯一变化的部分。 5. Result：一个 Lambda 函数处理 agent 的结论，决定下一步动作（批准，或退回修改）。 图示如下：水平流程依次是 Start、Extract、Identify、Route（Choice）、并行的 Organize-and-Validate 阶段、Result、End，Validate 分支被标为可更换，图例列出了它的四种实现方式：阻塞反模式、模式 1（task token）、模式 2（直接集成）、模式 3（durable function）。流水线本身在每种情况下保持不变，只有 Validate 分支被换掉来演示各自的调用模式。 同一个 Amazon Bedrock AgentCore agent 服务全部四种情况。agent 检查每次调用并选择如何响应：如果收到 AWS Step Functions 的 task token，就在完成时唤醒那个执行；如果收到 durable function 的 callback ID，就唤醒那个 durable function；两者都没收到，就直接在响应里返回结论。这意味着你可以更换编排模式，而不必修改或重新部署 agent。 agent 如何不阻塞调用方就把控制权交回来 机制是 agent 的 action group 里的一个"归还控制权"动作。agent 推理结束后，调用一个 Lambda，把结果和 task token 发回 Step Functions。（后面的模式 2 会让 Step Functions 直接与 AgentCore 集成，完全省掉这个 Lambda。） 下面这段代码是这个 Lambda 的核心： The tool the agent calls once it reaches a verdict @tool def conclude_validation(approved: bool, issues: list, summary: str) -> str: verdict = {"approved": approved, "issues": issues, "summary": summary, "source": "agentcore"} # A Step Functions task token was passed: resume that execution if task_token: sfn.send_task_success(taskToken=task_token, output=json.dumps(verdict)) return "Step Functions resumed." # A durable-function callback ID was passed: resume the durable function if callback_id: lambda_client.send_durable_execution_callback_success( CallbackId=callback_id, Result=json.dumps(verdict).encode("utf-8")) return "Durable function resumed." # Neither was passed: this is a synchronous call, return the verdict inline return "Verdict recorded." 入口函数根据同样的信号决定在后台跑还是同步跑： @app.async_task async def validate_document_async(prompt, document, extracted_text): # Background work; conclude_validation fires the right callback when done agent = build_agent() await agent.invoke_async(message(prompt, document, extracted_text)) @app.entrypoint async def handler(event): task_token = event.get("taskToken") # passed by the task-token pattern callback_id = event.get("callbackId") # passed by the durable-function pattern # Asynchronous: start the work and return "accepted" right away if task_token or callback_id: asyncio.create_task(validate_document_async(...)) return {"status": "accepted"} # Synchronous: run now and return the verdict in the response agent = build_agent() await agent.invoke_async(message(...)) return verdict agent 就位之后，本文剩下的部分聚焦于调用它的四种方式。代码和基础设施定义都是示例中的摘录，用来演示每种模式。 调用 agent：四种方式 先讲阻塞式反模式以确立基准成本，再展示避开它的三个模式。 阻塞式反模式 最直接的实现：在同一个 Lambda 函数里调用 agent 并等待答案。它能用，而且实现简单——这正是它如此常见的原因——但函数在 agent 思考的整个期间一直活着。 // The Lambda function blocks here until the agent responds const response = await agentcore.send( new InvokeAgentRuntimeCommand({ agentRuntimeArn: AGENT_RUNTIME_ARN, payload: new TextEncoder().encode(JSON.stringify(payload)), runtimeSessionId: sessionId, }) ); // The function stays alive and billed for the entire time the agent is thinking. 函数的计费时长最终大约等于 agent 的处理时间。后面三个模式消除这段空闲成本，各自做出不同的取舍。特别是模式 2 使用 Step Functions 对 AgentCore Harness (InvokeHarness) 的优化集成，完全去掉 Lambda。 模式 1：task-token 回调 + 派发函数 这个模式在路径里保留一个 Lambda 做自定义逻辑，但去掉空闲成本。Step Functions 用 waitForTaskToken 集成调用这个函数——传入一个 task token 后暂停执行。函数用这个 token 启动 agent，然后在几秒内返回。执行保持暂停，不产生任何计算计费，直到 agent 用这个 token 调用 SendTaskSuccess 恢复它。 // Start the agent, pass the task token, and return without waiting const response = await agentcore.send( new InvokeAgentRuntimeCommand({ agentRuntimeArn: AGENT_RUNTIME_ARN, payload: new TextEncoder().encode(JSON.stringify({ ...payload, taskToken })), runtimeSessionId: sessionId, }) ); // Returning here does not complete the step. Step Functions stays paused until // the agent calls SendTaskSuccess with this task token. return { dispatched: true }; 对应的状态从上下文取出 token，并设置超时和心跳作为安全网——这样沉默的 agent 会让执行干净地失败，而不是无限期停在那里： "ValidateDispatch": { "Type": "Task", "Resource": "arn:aws:states:::lambda:invoke.waitForTaskToken", "Parameters": { "FunctionName": "${ValidateDispatcherFunctionArn}", "Payload": { "taskToken.$": "$$.Task.Token", "document.$": "$.document", "extractedText.$": "$.extract.extractedText", "executionId.$": "$$.Execution.Id" } }, "TimeoutSeconds": 120, "HeartbeatSeconds": 60, "Next": "AgentCoreValidation" } 成本。 Lambda 函数仍然会跑，但只跑到启动 agent 并返回为止：几秒钟，无论 agent 之后要跑多久。你只为这次短暂派发付费，不为等待付费——因为函数在 agent 干活时已经关掉了。等待由暂停的 Step Functions 执行承担，它不为空闲计算计费。这是与阻塞版本的关键区别：阻塞版本里函数的计费时间跟着 agent 的处理时间走。 模式 2：直接服务集成 当你不需要围绕 agent 调用写自定义代码时，可以去掉派发函数，让 Lambda 完全离开路径。Step Functions 可以通过 AWS SDK 服务集成直接调用 Amazon Bedrock AgentCore，所以 agent 的响应直接流入下一个状态。Validate 分支于是变成单个 Task 状态： "ValidateDirect": { "Type": "Task", "Resource": "arn:aws:states:::aws-sdk:bedrockagentcore:invokeAgentRuntime", "Parameters": { "AgentRuntimeArn": "${AgentRuntimeArn}", "RuntimeSessionId.$": "States.Hash($$.Execution.Id, 'SHA-256')", "Payload.$": "States.JsonToString($.prep.agentInput)" }, "ResultSelector": { "raw.$": "$.Response" }, "TimeoutSeconds": 120, "Next": "ParseVerdict" } 成本。 路径里没有 Lambda，所以没有空闲的 Lambda 计算可付。Step Functions 承担等待，Standard 工作流按状态转换计费而不是按等待时长计费——处理期间的实质成本只有 agent 本身。 模式 3：Lambda durable function 如果你更愿意用代码而不是状态机来表达编排，Lambda durable function 给你同样的成本行为。用 @aws/durable-execution-sdk-js SDK，流水线阶段变成 context.step 调用，并行工作变成 context.parallel，等待 agent 变成 context.waitForCallback。等待期间函数挂起，不计计算费。agent 用 SendDurableExecutionCallbackSuccess 恢复它。 // Suspend the function until the agent calls back const result = await ctx.waitForCallback( "validate-agentcore", async (callbackId) => dispatchAgentCore(callbackId, document, extractedText, executionId), { timeout: { seconds: 120 } } ); 成本。 一个函数承载整条流水线，但挂起等待 agent 期间不按计算计费。你只为挂起之间短暂爆发的那几次执行付费——与 task-token 模式相同的经济性——而不是为等待付费。 测量差异 重点不是某个具体数字。agent 的运行时间随提示词、模型和文档变化。重要的是 task-token 模式里两个值之间的关系：Validate 状态活跃了多久，对比派发函数实际被计费了多久。我们测试中的单次运行让这个关系可见： Step Functions, ValidateDispatch state Returned (TaskSubmitted): 14:08:19 <- the function returned and shut down Resumed (TaskSucceeded): 14:08:34 <- the agent woke the execution State active ........ 19.6s Lambda, dispatcher function (CloudWatch REPORT) Billed duration ..... 4.8s Result: the state was active for 19.6s, but the function was billed for 4.8s. The ~14.8s in between is wait time with no Lambda function running. 在 Step Functions 的事件历史里也能看到同样的事：task-token 模式下，TaskSubmitted 事件（函数返回）与 TaskSucceeded（agent 恢复流程）之间隔着 agent 的处理时间。同步调用没有这样的间隔。 下表总结了每种模式下 Validate 分支（前面图示中高亮的部分）的实现方式： • 编排器：阻塞＝Step Functions；模式 1＝Step Functions；模式 2＝Step Functions；模式 3＝Lambda（代码） • 路径中的 Lambda：阻塞＝有，存活且计费；模式 1＝有，但提前返回；模式 2＝无；模式 3＝durable function 本身（挂起） • 等待期间的空闲 Lambda 计算：阻塞＝为整个等待付费；模式 1＝无；模式 2＝无；模式 3＝无 • agent 调用周围的自定义代码：阻塞＝有；模式 1＝有；模式 2＝有限（状态转换）；模式 3＝有 • 调用方与 agent 解耦：阻塞＝否；模式 1＝是；模式 2＝否；模式 3＝是 • 相对复杂度：阻塞＝最低；模式 1＝较高（token 和回调的 IAM）；模式 2＝最低；模式 3＝中等（检查点/重放） 读这张表时有一个提醒：总流水线时长不是有用的比较指标，因为它被 agent 自己的推理时间主导——每次运行都不同，而且在所有场景里基本相同。有意义的差异是等待期间你为多少计算付了钱，这由上表和计费时长读数体现。agent 运行时间增长时，派发函数的计费时间保持平稳。上面的数字来自单次运行，把它们当作这个关系的示意而非基准，请测量你自己的负载。 如何选择模式 下表总结了取舍，帮你选择模式： • 调用方成本：阻塞＝整个 agent 处理时间；模式 1＝几秒（仅派发）；模式 2＝零（无 Lambda）；模式 3＝几秒（仅派发） • 集成工作量：阻塞＝低；模式 1＝中高（IAM、心跳、超时）；模式 2＝低（单个 Task 状态）；模式 3＝中等（检查点-重放模型） • 业务逻辑位置：阻塞＝在 Lambda（前 + 后）；模式 1＝在 Lambda（前 + 后）；模式 2＝只在 Amazon States Language（ASL）（内置函数）；模式 3＝在 Lambda（顺序代码） • 最适合：阻塞＝原型、短 agent；模式 1＝自定义前后处理逻辑；模式 2＝纯编排、无自定义代码；模式 3＝单个函数里的复杂异步工作流 最佳实践 防 agent 永不回答。 给每个 waitForTaskToken 状态设置 TimeoutSeconds，让执行以 States.Timeout 失败，而不是无限期挂起。如果你的 agent 发送心跳，也设置 HeartbeatSeconds 以更快发现死掉的 agent。捕获错误并路由到失败或人工审核路径。 重试时使用稳定的会话 ID。 把 sessionId 设为从执行上下文派生的值（比如 Step Functions 执行名），这样重试会恢复同一个 agent 会话，而不是重新开始。task-token 模式里在派发函数中设置；直接集成模式里在 Task 状态参数中设置。 打开 AWS X-Ray。 在 Step Functions 和 Lambda 配置中启用 Tracing: Active。X-Ray 会精确显示 agent 思考了多久、调用方等待了多久，确认你的模式确实在间隔期间释放了计算。 按速度而不是按 agent 的负载来配派发函数。 派发函数只序列化请求并调用端点。256 MB 内存和 30 秒超时通常就够。重活都在 agent 那边。 成本 这些模式会产生 Lambda 计算、Step Functions 状态转换、durable function 执行存储的费用，以及所有方案共有的 Amazon Bedrock AgentCore runtime 和 Amazon Bedrock 模型推理费用。agent 和模型成本在四种情况下相同。架构只改变编排开销，以及阻塞反模式中浪费的空闲 Lambda 计算。当前价格请查看各服务的定价页。 结论 把 AI agent 放进流水线是简单的部分。让它被经济地调用，才是区分原型与生产设计的地方。阻塞在 agent 上的 Lambda 函数实现简单，却在悄悄烧钱——计费时间里的大部分都在等待。本文展示了三种规避方式：需要在路径里保留 Lambda 时用 task-token 回调；最简单的情况用直接服务集成；偏好用代码表达编排时用 durable function。三者由同一个 Amazon Bedrock AgentCore agent 驱动，它会根据被调用方式调整自己的响应。 完整示例（完整的 agent、状态机定义和 durable function）在 GitHub 的 sample-bedrock-agentcore-async-stepfunctions 仓库。想深入的话，可以看 Amazon Bedrock AgentCore 关于异步任务处理的文档。生产部署请使用 Amazon Bedrock Guardrails，对 agent 的输入输出实施负责任 AI 控制。 原文： #Bedrock# #Serverless# #StepFunctions#

HuggingFace 独立研究者 AuroraAI-Research 把语言模型压到了 8 万参数——训练是在一台小米手机的 CPU 上完成的。 《Aurora-80K：一个现代微型语言模型》 Aurora-80K 是 AuroraAI-Research 发布在 HuggingFace 上的微型语言模型：正好 8 万参数，Apache 2.0 许可，整个权重文件只有约 0.3MB。作者称这是 Aurora 系列的新起点，用来取代之前那些"低效的旧模型"，更大尺寸的版本已在路上。 最有意思的是词表设计。8 万参数的模型通常只能用几百词的词表，它却塞进了 4096 词表——靠分解表示：嵌入层拆成 64 个 cluster 向量和 64 个 sub-token 向量，相加组合出全部 4096 个词。128 个向量就顶起一张 4096 宽的嵌入表。 输出层同样分解。推理时先预测 cluster（64 选 1），再在 cluster 条件下预测 sub-token（64 选 1），两级合起来就是完整的 4096 词表概率。输入输出两头都省。 架构是现代配置的极简版：2 层 Transformer、hidden 64、SwiGLU 前馈、RMSNorm、ALiBi 位置编码配 256 的注意力窗口、4 头注意力。评测数字：Wikitext-2 BPB 3.2902，BLiMP 52.31%，Arc-Easy 26.05%。 训练数据是 fineweb-edu 按教育分 4 分以上过滤出的约 4000 万 token，跑 2 个 epoch。训练设备是小米 14T Pro，钉在 4 个 Cortex-X4 CPU 大核上，算上预处理和 tokenizer 训练，全程约 6 小时。 适合玩极限压缩、或者想研究"现代架构缩到最小长什么样"的人。仓库里权重、tokenizer、 齐全，装个 torch 就能在 CPU 上跑。AuroraAI-Research 主页还会更新更大的尺寸。 原文： #Aurora80K# #TinyLM# #开源模型#

43 个可安装的 AI 编码 skills，一条 npx 命令同时装进 Claude Code 和 Codex——从模糊想法到合并的 PR，整个交付流程有了统一闭环。 《Agent 工作流工具包》 agent-workflow-kit 是一个把"想法 → 合并的 PR"完整开发流程打包成 43 个可安装 skills 的开源工具包，同时支持 Claude Code 和 Codex 两个编码 agent，来自一个德语项目团队的内部实践沉淀（README 自述）。 一条命令装机。 在目标仓库根目录跑 npx github:iKon85/agent-workflow-kit init，skills 和辅助脚本会同时写入 .claude/skills（Claude Code）和 .agents/skills（Codex）。装完跑一次 /setup-workflow，它会探测你的 issue tracker，把 label、GitHub Projects 的字段 ID 写进配置——board 脚本里没有任何硬编码的 ID。 四阶段闭环。 Plan 阶段有 grill-me / grill-with-docs 拷问需求、to-prd 把想法变成 Draft-PRD、to-issues 拆成原子 issue（1 个 slice 一个 issue，多个 slice 升成 wave anchor）；Execute 阶段是严格的 tdd 红绿循环和 implement；Land 阶段 make-landable 跑本地 CI 闸门，land 负责 push、合并 PR、清理 worktree，pre-commit 钩子自动挡坏提交；Learn 阶段 retro 做复盘，把教训写回 rules 配置。另有 codex-review / codex-build 用第二个模型交叉审查 plan。 更新不覆盖你的改动。 init 会记录每个文件的 sha256。update 时你自己改过的文件先备份成 .bak 再替换，或者用 own 声明某个文件永久归你，更新直接跳过。kit 无遥测、MIT 许可，43 个 skills 里有一部分改编自 Matt Pocock 的开源 skills，每个都带 THIRD-PARTY-NOTICES 标注来源。 可选的 wave 管理。 board-to-waves 把积压 backlog 聚类成主题波次；当 slice 之间文件不相交、spec 锁定时，orchestrate-wave 可以端到端落地整个 wave——每个 slice 派一个 implementer 进独立 worktree，常常 AFK 跑完。 适合想让编码 agent 从"聊天写代码"升级成"按流程交付"的团队或个人。要求 Node ≥ 20、Claude Code 或 Codex；repo 今年 6 月才开源，还在 0.x 迭代，流程文档和更新机制已经相当完整，建议先在项目里小范围试。 原文： #AgentWorkflow# #ClaudeCode# #Codex#

把一千篇真实论文丢给三个模型做摘要，同一份语料、同一份 prompt：DeepSeek 的 Flash 跑完全部只花 $3.99，Claude 的 Haiku 花了 $35.76。 《年度 AI 论文：2025–2026 年的关键研究》 一年 1,000 篇论文的图鉴，外加一个成本实验。 是 Hassan El Mghari（GitHub 上的 Nutlope，Together AI 生态的知名开源开发者，做过 roomGPT、SmartPDFs 等热门项目）做的「年度 AI 论文」站点：2025 年 8 月 4 日到 2026 年 8 月 4 日这一年的 1,000 篇论文，每篇都有摘要，可按实验室、主题、月份浏览。整个项目的起点其实是个成本实验：把这一年的论文全部摘要完，要花多少钱？ 基准结论：同一份输入，三个模型差了 8.95 倍。 语料合计 30,681 页、1.027 亿字符。三个模型拿到完全相同的提取文本、prompt、分块方式和输出合同，关闭 reasoning，各跑一遍： • DeepSeek V4 Flash：合计 $3.99，每篇约 $0.004 • GPT-5.6 Luna：合计 $6.00，每篇约 $0.006 • Claude Haiku 4.5：合计 $35.76，每篇约 $0.036（8.95×） 费用按官方报价的 token 用量计算，价格冻结在 2026 年 8 月 5 日；只统计成功完成的摘要，失败重跑不计入。 方法论可复现。 语料从 8,262 个候选（Hugging Face Daily Papers + OpenAI、Anthropic、DeepSeek、MiniMax、Moonshot AI 的官方论文）按 arXiv ID 去重，冻结成恰好 1,000 篇；放得进上下文预算的整篇一次读完，超长的走 50,000 字符的 map-reduce，不静默截断。作者明确说这是成本对比，不是质量排名——没有引入 LLM judge 打分。 图鉴本身也好看。 按实验室（OpenAI、Anthropic、Moonshot AI、DeepSeek、MiniMax、 275 篇、Reasoning 177 篇、Video 164 篇、Multimodal 144 篇、Systems 143 篇、Robotics 59 篇）、月份浏览；trending 和 most cited 两个榜单（Qwen3-VL 1,802 次引用、DINOv3 1,216 次、InternVL3.5 1,212 次）。再叠上 18 篇 Together AI 官方论文，共 1,018 篇。 适合想快速补完这一年 AI 研究的人，以及要批量处理 PDF 摘要、想先估成本的工程团队。全流程开源在 GitHub（Nutlope/1kpapers），语料清单、抽取画像、逐篇费用都能自己复现。 原文： #AI论文# #成本基准# #LLM#

两个 prompt 状态在置信度上可以几乎完全一样，同样的扰动打上去，一个纹丝不动，一个直接崩掉。 作者是 GitHub 上的一个匿名账号，这是他唯一的公开仓库，实验是和 ChatGPT 一起做的。 Prompt-State Response Geometry（提示-状态-响应几何） 这不是一篇论文。 它是一个小爱好项目，起点是一个简单的问题： 只靠改 prompt，能不能让 LLM 更可靠地回忆起事实信息？ 几天之后，我们到了一个自己也没预料到的地方。 主要观察是： 几乎一致的局部置信度，并不意味着几乎一致的扰动响应几何。 我们分享代码和原始输出，是因为这个实验足够小，可以直接检查；也因为比起假装自己有了最终答案，我们更愿意让别人来复现、拆解、扩展或解释它。 我们不宣称发现了新的 transformer 机制、幻觉检测器，或者语言模型的某种普遍性质。 核心对照 最终实验只改变同一组证据多重集的顺序。 在每个证据族内部： • 证据值完全一致 • 各值出现次数完全一致 • 逐条证据行完全一致 • 任务字符长度完全一致 • 基线 token 长度完全一致 • 配对的两边还会逐条件审计 token 长度是否相等 最重要的是： 配对是在任何扰动结果被打分之前，用基线置信度统计量选出来的。 因此之后的扰动结果不可能影响哪些状态被配对。 这种结果盲选的配对方式，是我们认为最终实验比早期探索版本更有用的主要原因。 基本想法 假设一个模型正在预测某个 token。 我们可以用一些局部统计量来描述这个预测，比如： • 目标 token 的概率 • 对数几率 • 熵 • rank 我们开始对一个不同的问题感兴趣： 如果两个 prompt 状态在这些局部置信度统计量上看起来几乎一样，当周围上下文发生一点变化时，它们的反应也相似吗？ 在这个受控的 Granite 实验里，它们经常不相似。 我们发现有用的一个心智模型是： • 置信度是一张快照 • 扰动响应是附近的地形 两个点可以有相同的海拔，却有完全不同的周围地貌。 起点：Gemma 这个更广泛现象的第一个版本，出现在我们折腾 Gemma 4 26B-A4B 的时候。 当时我们用的是 llama.cpp / GGUF 配置，在观察事实回忆的边界。 其中一个例子是 Rust 的创造者： Graydon Hoare token 路径里有一个边界： Graydon Ho | are 模型对名字的靠前部分可以极其稳定，而最后延续部分的概率在伴随 prompt 下会剧烈变化。 例如，从 Graydon 延续到 Ho 的概率一直维持在接近饱和的水平，而从 Graydon Ho 延续到 are 的概率，会视周围 prompt 状态的不同，从极高置信度掉到个位数。 一开始我们几乎怀疑一切： • 采样 • llama.cpp • 量化 • prompt 模板 • KV/cache 行为 • 分词 • 或者只是一个奇怪的、模型特有的伪影 于是我们不再把 Gemma 的结果单独当作强证据，转而去搭一个更干净的设置。 Gemma 的观察和最终的 Granite 实验不是同类对照复制。它们在架构、模型家族、后端、模型规模等细节上都不同。 我们只把 Gemma 当作一条汇合证据：我们看到的更广泛的 prompt 状态敏感性，显然不是最终 Granite 设置独有的。 这个仓库里精确的随机顺序配对实验，是在 Granite 上做的。 受控的 Granite 设置 我们换成了： ibm-granite/granite-4.1-3b 用原生的 Hugging Face Transformers，配置是： float32 attn_implementation="eager" use_cache=False 不采样 不用 GGUF 不量化 teacher-force 的 next-token 打分 这从之前的设置里拿掉了好几个活动部件。 合成任务 我们造了一个临时性的虚构记录任务，用四个可能的值： Igor Sysoev Igor Sokolov Igor Smith Igor Petrov 目标延续是： Igor | Sy 我们 teacher-force： " Igor" 然后给： " Sy" 打分。 证据由重复出现的虚构记录组成，例如： K7 -> Igor Sysoev K7 -> Igor Smith K7 -> Igor Sysoev K7 -> Igor Petrov ... 在一个证据族内部，只有这些证据行的顺序变化。 最终验证里不使用记录编号，所以重排不会悄悄改变逐行记录的字面内容。 随机顺序验证 最终实验用五个证据数量族： 6 / 1 / 4 / 1 4 / 3 / 1 / 2 5 / 0 / 5 / 4 5 / 4 / 1 / 2 6 / 5 / 3 / 0 每个族采样： 768 个互不重复的随机排列 总共： 3840 个基线 prompt 状态 脚本在打分之前先做结构检查。 结果盲选的配对 我们不会先看扰动结果、再挑看起来有趣的配对。 配对只从基线测量里选。 默认标准是： rank = 1 P(correct) 在 0.80 到 0.995 之间 delta log-odds 的绝对值 <= 0.01 delta entropy 的绝对值 <= 0.02 配对选择发生在扰动打分之前，选中的配对在每个族内部互不重叠。 冻结下来的选择保存在： results/selected_pairs.json 扰动 配对冻结之后，同样的 12 个伴随扰动被施加到每一对的两个状态上： repeat LUMA repeat NOVA repeat KITE repeat 4827 copy LUMA copy NOVA copy KITE copy 4827 write LUMA write NOVA write KITE write 4827 这些是小的伴随任务，不改变虚构的 K7 证据本身。 对每个状态，我们测量目标 token 的对数几率相对它自己的基线移动了多少。 这给出一个 12 维的响应向量： [dLO_1, dLO_2, ..., dLO_12] 对每一对配对，主要的比较指标是： profile MAE 也就是两个响应向量之间逐条件的平均绝对差。 最终结果 随仓库附带的随机顺序验证产出了： 配对数量 N：20 基线 delta LO 中位数：0.00079255 profile MAE 均值：2.9246 profile MAE 中位数：2.2979 profile MAE 最大值：10.0046 配对的基线可以极其接近。 比如有一对大约是： 基线 P(correct)： 93.613813% 93.614706% delta log-odds： 0.0001493 而它的扰动 profile MAE 是： 2.8936 另一对的基线对数几率差只有大约： 0.00107 profile MAE 却大约是： 10.00 在若干对里，一个状态在多数甚至全部扰动下丢掉了 top-1 的位置，而它基线配对的一方没有。 所以，在这个设置里： 把局部预测匹配得非常接近，并不能保证这个预测对附近上下文变化的响应方式也被匹配。 一个简单的样本内对照 对第一版 README 的一个有用的批评是：「2.92，跟什么比？」 不需要再跑一次模型，我们就能回答其中一部分。 被选中的集合有 40 个状态：5 个证据族，每族 8 个。 我们把 20 对结果盲选的置信度配对，跟同样这 40 个状态里族内的其他配对做了比较。 • 配对数量：匹配配对 20，族内其他配对 120 • profile MAE 均值：匹配配对 2.9246，族内其他配对 3.0348 • profile MAE 中位数：匹配配对 2.2979，族内其他配对 2.1155 在这个选中的集合里，非常紧的置信度匹配并没有让扰动响应 profile 比族内其他配对明显更相似。 我们不把这解释为「置信度不包含任何信息」。这是在已经选出来做 profile 打分的 40 个状态之间做的描述性、条件化的比较，不是对全部 3840 个基线状态的总体层面统计检验。 但它让那个窄结论更容易陈述了： 匹配这些局部置信度统计量，不足以决定扰动响应 profile。 对数几率与概率饱和 这个项目更早的版本用被截断的概率计算对数几率。这在概率接近饱和时，数值上可能产生误导。 最终实验不用那个指标。 对数几率直接从 logits 计算： target_logit - logsumexp(all_other_logits) 指标的运算全程在 float64 里完成。 一些被扰动的状态仍然会接近概率饱和，所以即使没有旧的数值 bug，大的对数几率也会自然出现。 作为描述性的敏感性检查，我们把被扰动的对数几率截断在 99.99% 置信度对应的量级。 • 原始 profile MAE 均值：2.9246 • 截断后 profile MAE 均值：2.7263 效应变小了一点，但没有消失。 这个截断检查是对随附输出的离线分析，不属于配对选择的一部分。 我们认为这意味着什么 我们不认为置信度没用。 在早期的探索性实验里，置信度和敏感性经常按预期的方向相关：高置信度的预测总体上比不确定的预测更稳定。 这里更窄的观察是： 局部置信度统计量看起来并不能唯一地决定局部扰动行为。 两个状态按这些指标可以看起来几乎一样： P(correct) log-odds entropy rank 却在同一组扰动下有着非常不同的响应 profile。 因此，如果我们关心的是一个状态在附近上下文变化下如何表现，单张局部置信度快照可能是一个不完整的描述。 与 prompt 敏感性的关系 prompt 敏感性本身不是新东西。 众所周知： • prompt 措辞有影响 • few-shot 示例顺序有影响 • 上下文顺序有影响 • 语义相似的 prompt 可以产出不同的输出 我们的实验问的是一个更窄的问题。 不是只问： 改 prompt 会改变预测吗？ 而是问： 如果两个 prompt 状态在当前预测边界上已经看起来几乎一样，它们对之后同样的扰动，反应也相似吗？ 我们受控的 Granite 结果表明答案可以是：不。 我们刻意不做比这更强的原创性声明。 这不证明什么 这个仓库不证明： • 幻觉检测器 • 所有 LLM 的某种普遍性质 • 新的 transformer 机制 • 证据顺序总是有影响 • 某一种排序策略全局更好 • 置信度没用 • 事实记忆特别脆弱 • post-training 造成了这个效应 确切的内部机制未知。 可能的解释涉及位置、注意力历史、上下文表征、残差流状态，或者完全别的东西。 我们没有把这个机制分离出来。 重要局限 最终的受控实验仍然是窄的。 一个受控模型 精确的随机顺序配对实验是在 ibm-granite/granite-4.1-3b 上做的。 Gemma 4 26B-A4B 更早显示了这个更广泛的现象，但精确的随机顺序设计没有在它上面复现过。 一个合成任务 最终实验用的是： Igor Sysoev Igor Sokolov Igor Smith Igor Petrov 其他的 token 几何或合成任务可能表现不同。 一类扰动 这 12 个扰动是手工设计的。 它们不是从所有可能的伴随 prompt 里随机抽样的。 匹配的是汇总统计量，不是完整分布 配对按目标概率/对数几率、熵和 rank 匹配。 我们没有匹配完整的基线 next-token 分布。 因此两个状态可以有相似的目标置信度汇总，却在对手 token 上的详细分布不同。 更严格的未来对照可以直接匹配或约束完整分布的散度。 描述性结果 这个仓库专注于展示和复现这个观察。 我们不提供正式的推断统计，也不宣称一个总体层面的效应量。 我们为什么停止测试 总还有下一个可能的对照。 我们可以测： • 另一个模型家族 • 另一组名字 • 另一个合成任务 • 随机扰动族 • 不同的 token 边界 • 隐藏状态相似度 • 完整 next-token 分布匹配 • 更大的排列集合 到某个点，我们认定更有用的做法是：发布一个最小可复现的版本，让别人来攻击它。 如果这个观察在更好的对照下消失了，那是有用的。 如果它在别处复现了，那也是有用的。 复现实验 这个仓库刻意只包含一个主实验脚本： 运行： python 默认运行每个证据族采样： 768 个排列 并把输出写到： random_order_validation/ 脚本支持 checkpoint，中断的运行可以恢复。 更大的排列搜索： python --n-per-family 1500 随附结果的生成环境 随附的输出是用这些生成的： Python: 3.14.4 PyTorch: 2.12.0+rocm7.14.0 Transformers: 5.14.1 HIP: 7.14.60850 GPU: AMD Radeon RX 7900 XT 模型： ibm-granite/granite-4.1-3b 模型设置： float32 eager attention use_cache=False ROCm 版 PyTorch 通过普通的 device = "cuda" 接口暴露 GPU。 仓库内容 README.md LICENSE requirements.txt .gitignore results/ final_summary.json selected_pairs.json baselines.jsonl profiles.jsonl run_output.txt baselines.jsonl 是基线排列扫描。 selected_pairs.json 是冻结下来的结果盲选配对。 profiles.jsonl 是扰动打分。 final_summary.json 是最终的配对级指标和结构审计。 run_output.txt 是那次运行的原始终端输出。 关于讨论与回应 这是一个爱好项目，不是一个我们打算无限期维护的研究计划，也不是一篇我们打算无限期辩护的论文。 我们分享代码、原始输出、方法和局限，这样实验可以被检查，而不需要信任我们本人。 我们可能不回应评论、issue、私信、辩论请求，或者每一个被提议的后续实验。 没有回应不应该被解释为同意、不同意，或者对某个批评有效性的表态。 如果你发现了实验的问题，那是有用的。挑战这个结果最有用的方式是：复现它、改代码、跑一个更强的对照，或者给出一个反例。 我们没有这个仓库会成为长期研究项目的预期。如果有什么值得加的，我们可能更新它；也可能就让它保持原样。 AI 协作 这个项目是仓库主和 ChatGPT 协作开发的。 最初的方向来自仓库主： prompt 设计能让 LLM 更可靠地回忆起信息吗？ 从那以后，随着意外行为不断出现，项目反复转向。 仓库主在本地跑模型，通过质疑实验选择、发现设置问题、否决死胡同、推动更干净的对照来引导调查，包括在后端和采样问题变得重要之后，离开 llama.cpp。 大部分实验代码和大部分详细的定量分析，是由 ChatGPT（OpenAI）在交互式会话中产出的。 ChatGPT 也根据实验历史、代码和记录的结果写了这份 README，经仓库主审阅和指导。 所以这个仓库不应该被读成： 「一个人类研究员写了所有东西，偶尔用 AI 自动补全。」 那不准确。 更好的描述是： 我们交互式地探索了这个问题：仓库主提供了最初的想法、本地执行、怀疑和方向；ChatGPT 提供了大部分代码、定量分析和实验迭代。 我们明确披露这一点，因为没有理由隐藏它，尤其是在一个关于语言模型的项目里。 代码和原始输出都在仓库里，所以谁都不用信任我们两个中的任何一个。 请复现它、拆掉它、简化它，或者找到一个更好的解释。 做这些事不需要我们的参与。 许可证 这个仓库以 The Unlicense 发布。 意图很简单： 用它、抄它、改它、fork 它、扩展它，或者扔掉它。 不需要我们许可。 模型、PyTorch、Transformers 和其他第三方依赖的许可证与条款仍归它们各自所有。 原文： #LLM# #PromptEngineering# #AI实验#

决定代码复杂度的东西不在代码里，在写代码的人的脑子里。LLM 碰不到它。 这是 软件工程师 Pol Alvarez Vecino 读完 Peter Naur 1985 年的论文后得出的结论。 为什么 LLM 没法让你的代码更简单 本文最初发表于 Medium（ tl;dr：Peter Naur 的《Programming as Theory building》指出，真正的程序——他称之为 Theory，大写的 T——存在于工程师的脑子里。代码和文档只是下游的（因而不完整的）产物。我对 LLM 最大的抱怨之一，就是它写出来的代码有多啰嗦、复杂度是怎样到处蔓延的。我一直抱着一丝信念：也许我们可以用 LoC 或者独立代码路径数量之类的指标来约束它们。然而，读完 Naur 之后我意识到，我们想降低的那个复杂度是 Theory 的复杂度，不是代码的复杂度，而这方面没有任何可用的度量，因为它非常主观。 我最近读了 Peter Naur 那篇精彩的论文《Programming as Theory building》（ LLM 能做什么、不能做什么的看法，也改变了我对如何给它们写提示词、当前 agent 系统的主要局限，以及结对编程为何如此有效的看法。 今天我只聚焦它和代码复杂度的关系。 如果你还没读过这篇论文，我真的建议你读一读。说实话，我写这篇文章的主要目的，就是让一些人去读原论文。它值得花这个功夫。这也是练习（或学习！）在 Solveit 里做精读的绝佳机会，因为在 Solveit 里这要容易得多：你可以在阅读过程中随时提问，钻进任何你感兴趣的兔子洞，或者直接让 Solveit 帮你把语言讲清楚。关于精读的更多信息见这篇博文（ fork 我的对话记录快速上手（ 话说回来，如果你还是决定不读，这里是论文的 tl;dr： 程序是构建和维护它的人所持有的 Theory：一种理解——程序如何与现实世界的问题相关联，哪些约束和权衡塑造了它，它为什么能工作，以及哪些改动符合它的设计。代码和文档是这套 Theory 的下游产物，永远无法完整地承载它。 工程师通过经验发展出这种理解：与用户交谈、观察故障、学习领域知识、观察系统在真实世界中的表现。这种理解指导着对相关性、相似性、简洁性和良好设计的判断。 LLM 不太擅长持续学习，不擅长和用户交谈，也不擅长在真实世界里体验事物。但这和复杂度有什么关系呢？ 我想我们都同意：LLM 总体上倾向于让代码库的复杂度上升，如果没人管的话。原因有很多：它们没意识到某个方法已经存在，于是又写了一遍；它们写过度防御的代码，比如为不可能发生的边界情况做防护；或者过早地过度优化。顺便说一句，大多数前沿实验室从你消耗的 token 里赚大钱，所以它们多少有动机去推广 token 最大化。总而言之，LLM 很少遵循 KISS 原则。这个问题在你不看输出、纯 vibe-coding 的时候最严重。但即使你会审查代码，要想让程序保持简洁，也需要主动付出努力去尽量削减复杂度。 在我天真的日子里（大约两周前），我曾以为我们早晚能爬出这个复杂度的大坑。前沿实验室只需要在 RL 训练里加一些复杂度惩罚就行。他们可以用总 LoC 作为最小化的指标，但我们都同意，有时候一行代码比两三行更复杂。另一个选项是圈复杂度（cyclomatic complexity），它衡量独立代码路径的总数。读完 Peter Naur 之后我意识到，这些东西无法真正解决问题（也许能稍微缓解一点）。我们来看看为什么。 为什么代码复杂度是错的指标 在下面这个（我编的）例子里，我们想支持调用 OpenAI 和 Anthropic。假设所有的消息准备和重试逻辑完全一样，只有请求体参数略有不同，于是我们有两个不同的方法 call_openai 和 call_anthropic。 在第一个朴素版本里，我们有两个不同的类，带重复的样板代码（即 prepare 和 with_retries）。 分开 —— 指标会发现重复 class OpenAIClient: def complete(self, prompt): msgs = prepare(prompt) # 公共样板代码 y = call_openai(msgs) # 唯一不同的一行 return with_retries(y) # 公共样板代码 class AnthropicClient: def complete(self, prompt): msgs = prepare(prompt) y = call_anthropic(msgs) return with_retries(y) 一个直接的 refactor 是创建单个类，做到 DRY。按很多指标看这都是更好的实现：行数更少、Halstead 容量更好（V=N×log2(n)，N 为程序长度，n 为词汇量）、可维护性指数（Maintainability Index）也更好。 合并版 —— 按指标看确实更好：DRY，行数更少 class LLMClient: def __init__(self, provider): self.provider = provider def complete(self, prompt): msgs = prepare(prompt) y = call_openai(msgs) if self.provider == "openai" else call_anthropic(msgs) return with_retries(y) 一般来说，第二个版本（或者类似减少 LoC 和重复的版本）复杂度更低。但是，如果我告诉你，下个月我们很可能就停止支持 Anthropic 了呢？在那种情况下，我更倾向于让它们保持分开，这样到时候我只要删掉包含 AnthropicClient 的那个文件就行。 当然，这种简单的例子很容易解决，尤其是现在 LLM 可以帮你写代码。但如果你的目标不是 2 个供应商，而是像 LiteLLM 那样支持 165+ 个供应商呢？那种情况下，直接用 LiteLLM 就行。但那样你就把 120 多万行 Python 代码放到了你和最终供应商之间。值得吗？ 设计良好的 API 是抽象复杂度的绝佳方式。你有清晰的契约，不需要理解背后发生了什么。即使 LiteLLM 是一个庞大的包，它也可能不计入你的 Theory 总复杂度。LLM 推理端点早期的日子就是这样：「文本进，文本出」。然而，当契约不再可靠时，这一切就会崩塌。原因可能是它有 bug，可能是 API 背后藏着大量你拿不到的状态，也可能仅仅是你不确定某个新供应商特性是否被支持。 每当你被迫窥视 API 抽象层背后的深渊时，那份复杂度就成了你的问题。这个问题正变得越来越普遍。像 OpenAI 和 Anthropic 这样的供应商，越来越多地把数据藏在服务端，比如加密的压缩数据或推理 token（更多讨论见 如果你在快速推进、只用基础功能、想尝试很多供应商，那么 LiteLLM 或类似的库可能值得用。反过来，如果你看重控制力、调试和对技术栈的理解，那可能就不值得。不存在「正确的」复杂度（虽然我非常偏好第二种选择）。 进入 Theory 决定走哪条路的信息不在代码里。这些信息属于 Naur 所说的程序的 Theory 的一部分。迄今为止，LLM 几乎接触不到这些信息，因为它们活在人的脑子里。它们可以从 IM、邮件或其他书面文档里得到一些线索，但那些永远只是局部的（最好的情况下）。 其中一些信息可以作为上下文提供给 LLM，比如业务优先级、预期的产品变化、运维约束，以及早期决策背后的原因。这样做也许能改善它的选择，但这些仍然只是 Theory 的产物。它们无法完整地传递团队发展出这套 Theory 所依赖的经验和判断。 这些都很好，但如果我全身心投入 vibe-coding 和 token 最大化、完全不在乎代码呢？那样的话，这篇博客后面的内容说服不了你。如果你处于两者之间，我来描述一个我们在 亲身经历的真实情况，关于 Solveit 的计费系统。 剧透警告：在 最初的计费系统 Solveit 是一个平台，你可以在里面用 AI 在一个类 notebook 的环境里工作。环境是持久化的，所以我们对 LLM 用量、CPU、磁盘、内存和带宽收费。 最初的计划是向用户收月度订阅费（比如 5 美元）。这笔月度订阅费变成当月可以消耗的积分（credits），如果全部用完，下个月之前就得充值。我们先在一个更小的项目里测试了这套方法来验证它。 这套方法后来证明比我们想要的更复杂。第一，积分 + 订阅的机制会把人（比如我自己）搞晕。第二，它让代码在多个层面上更复杂。你得处理「先消耗月度订阅积分、再消耗普通积分」的所有逻辑，以及剩下的积分怎么办。在 Stripe 这一侧，它有两个不同的代码路径：手动充值和订阅服务。 对不熟悉的人来说，Stripe 订阅是一个全托管服务。Stripe 管理整个生命周期（扣款周期、发票、重试全在他们那边）。 你大致只需要这样创建订阅： stripe.Subscription.create(customer=cust_id, items=[{"price": "price_5usd_monthly"}]) 然后监听他们的 webhook，在订阅状态变化或付款到达时更新你的数据库（还有很多其他事件可以选择）。 直接收款则需要你启动一个 checkout session，让用户跳转到 Stripe 的域名填卡。这需要你提供一个 customer ID。那应该在什么时候创建 Stripe customer？用户注册时？他们尝试付款时？还是别的时机？全都是合理选项。 stripe.checkout.Session.create(mode="payment", customer=cust_id, line_items=[{"price": "price_5usd", "quantity": 1}], success_url="") 到目前为止还好吧？如果你对 Stripe 或支付没有太多经验，很可能你已经感到吃力，没法把这一切全装进脑子里。也许你设法把它简化成了： • 订阅 → 交给 Stripe 订阅服务管理 • 充值 → Stripe checkout 一个不明显的问题是：使用 Stripe 托管服务意味着你有重复的数据。一半数据在 Stripe 的后端，而你必须保证本地数据库和它同步。另一个问题是，调试的时候，你既要查 Stripe 的服务，又要查自己的数据库。比如，一笔付款没到账，是 Stripe 没发 webhook（「他们的错」），还是我们没把它存进数据库（「我们的错」）？ Stripe 订阅服务很棒、很容易上手，但它是为支持海量用例而设计的。这意味着，即使设计得很好（它确实很好），这个 API 抽象最终也相当复杂。在这种情况下，你在用「卷起袖子自己写代码的复杂度」交换「学习 Stripe API 的复杂度」。 LiteLLM 和 Stripe 在不同规模上展示了同一个权衡：只要契约成立，外部抽象能极大地简化你的 Theory；但每当你需要调试、修改或超出契约去推理时，它隐藏的复杂度就变成你的了。 AAI 的做法 在 经过很多天的探索和讨论，我们最终定下了一个简单得多的系统。 首先，我们只做积分（credits），按用量收费。这是一个超级简单的模型（和 Theory！）：充值积分，用多少付多少。 订阅一去掉，我们就可以删掉一大块用来保持同步的代码。剩下的付款路径只有两条：手动充值和自动充值。要做自动充值，你需要能保存客户的信用卡，以便随时扣款。而 Stripe checkout 不会保存信用卡，你只是让 Stripe 在他们的 UI 里处理这次付款。 长话短说，我们最终发现最简单的办法是：用户一注册就保存他们的信用卡。卡一旦在档，用户可以用它手动充值，也可以设置成自动充值。因为全部是我们自己处理的，同步问题几乎为零。我们只监听支付成功事件（没有订阅了！）。 结果就是，我们支付系统的 Theory 可以用一句话概括： 客户注册时添加信用卡，之后我们对该卡扣款——要么手动（充值），要么在余额不足时自动扣。 手动充值和自动充值现在走同一条支付路径。我们整个支付技术栈——拆在 Solveit 和 faststripe 之间——大约 300 行代码。 结果是非常低的复杂度，但这是数小时的探索、尝试和讨论换来的。我这里的解释充其量只是触及皮毛。 印度登场 那么上线那天发生了什么？一切顺利吗？没有。上线后我们发现，印度信用卡不支持你想什么时候扣就什么时候扣的 off-session 扣款。手动充值属于 on-session，仍然可以工作，因为用户会在我们的 UI 里看到一个类似 3DS 的验证流程；但自动充值不行。 在寻找解决方案时，我们发现 Stripe 托管订阅在印度确实能工作。为什么？因为 Stripe 替你绕开了所有这些复杂度。他们提前一天创建并持有 off-session 的支付意图（payment intent），这样银行就能在实际扣款前向用户发送预扣款通知或认证请求。 我们迁移出托管订阅时，就失去了这个特性。我问了一个前沿 LLM——我记得是 GPT-5.5——我们该怎么处理这个问题。你猜它给出的方案是什么？ 用回 Stripe 订阅来处理 这个 LLM 提议的正是我们刚刚迁移出来的方案。读到这里，你会怎么说？你的意见是什么？我们应该迁回去吗？ LLM 列出了两个选项：要么同时支持两套系统（随时可以开工，你一句话就行！），要么完全迁回旧的系统。我们做了什么？什么都没做。我们非常看重 Theory 复杂度，于是我们决定：让印度用户手动充值就好了（抱歉了各位！），换来一个更简单、更健壮的平台。 如果你不同意我们的选择，反思一下为什么不同意。真的，现在就停下来想一想。 这个问题没有正确答案，而这篇博客的目的之一，就是帮你看清你的答案来自哪里。你的论据是什么？更具体地说，它们是从哪里来的？ 有很多场景下 Stripe 托管服务是更优的选择。举几个例子： • 公司收入最重要，手动充值的额外摩擦可能会让我们损失一些印度销售额，那我们应该迁回去（或者同时支持两套） • 销售团队用 Stripe Dashboard 的 UI，所有支付信息都放在我们自己的数据库里并不理想，因为他们没法在那里管理 我的观点是：你的代码的复杂度，真的取决于一大堆和代码无关的因素，而那些信息不在代码里。 隐藏的优势 那么为什么不干脆让 LLM 全权处理这些事呢？在我看来，最妙的答案是：我们的工作方式揭示了一个可能的商业机会。印度不支持 debit mandate（借记授权）的方式和世界其他地方不一样。Stripe 试图解决这个问题，但远远不是一个完整的解决方案。 在理解和简化流程与 Theory 的过程中，我们学到了产品之外有价值的东西。在我看来，这类洞察是可以转化为竞争优势的。 努力去理解，本质上就是一个简化 Theory 的过程。如果你放任 LLM 在复杂度上为所欲为，你可以很快产出大量代码。选择简化路线更长、更费劲，但长远来看我认为它是值得的，而且你可能会在路上发现隐藏的宝石。 原文： #LLM# #编程# #代码复杂度#

同一批基准里，本地跑的 DeepSeek V4 Flash 加上 J-Space 控制层之后，在大多数任务上压过了不加控制层的 V4 Pro。 《DeepSeek V4 × J-Space 能力释放报告》 DeepSeek V4 × J-Space：Benchmark 与工程观察记录 © 2026 Tiger3807861189，本记录采用 CC BY-ND 4.0（署名-禁止演绎）许可。 页面范围：本记录整理外部项目已经公开的工程观察、J-Space 使用的操作性术语、项目级 Benchmark 分数及其适用边界。它不是研究论文，非学术性质，不提供模型内部机制证明、形式化判定方法、消融设计或因果贡献分解。 J-Space Cognition Suite V3.6 是一套在推理阶段运行的模型无关控制系统，不修改模型权重。项目地址： 一、外部工程观察 1.1 Anchored Standard：首轮接口锚定 dsh-anchored-standard（ DeepSeek Harness 的首轮接口条件。其基础方案在第一次模型请求中恢复 Minimal 的真实双工具 Schema，抑制自动注入内容；会话产生持久事件后，再开放一个较小的常驻工具目录，并按需解锁其他工具。 该项目的公开实验表明，首轮工具 Schema、输出预算和自动注入内容都可能改变首条推理轨迹。它也明确区分了"轨迹被锚定"和"任务能力已经稳定提升"：当前仓库中的通用组合与早期高分运行并不完全相同，小样本独立复现尚不足以确定稳定的能力增益幅度。因此，本记录只引用其接口敏感性与路径保持观察，不把单项分数推广为普遍结论。 1.2 Routing Suite：任务感知的入口选择 dsh-routing-suite（ 与工具面装配，把新会话送入不同的行为带。其公开材料报告了稳定区域和不稳定过渡区域，并据此避免把连续数值旋钮误当成可连续调节的推理深度。 该项目后来对早期"官方刻意设计双吸引子""自路由绝对不可能"等强归因作出了公开勘误（ mixed 表示不稳定的过渡或竞争区域，不等于一种兼具短、长思维优点的可用中间态。 二、思维链二极管 2.1 操作性定义 本记录所称思维链二极管（chain-of-thought diode），是一个面向黑盒行为的工程术语：在同一个会话中，连续思维链会稳定落入以下两种形态之一： • 短思维直觉：较快形成判断并进入行动，推理块较短； • 长思维推理：先展开较长的分析、重估与规划，再决定是否行动。 两种形态在同一会话中不能稳定、按任务阶段自然地共同出现；首轮形成路径承诺后，后续思维链通常延续同一侧。外部实验中偶尔出现的词汇混合或不稳定过渡，不构成能够同时利用两侧优势的中间态。 这一术语描述的是会话级轨迹，而不是某一句话或某一个词。We need、Let me 等表达最多只能作为外部探针，不能单独证明模型能力、推理质量或内部状态。 2.2 形成原因：极简接口过拟合假说 J-Space 采用的工程诊断是：DeepSeek 的 Agent 后训练行为可能与 DSH 极简模式的接口分布形成了过强耦合。极简 persona、首轮工具 Schema、自动注入边界和输出条件共同构成接口指纹；当实际 Harness 接近这一分布时，一类轨迹更容易被唤起，接口发生变化时则可能落入另一类轨迹。 这里的"过拟合"是对黑盒条件敏感性的工程概括，不表示已经获得 DeepSeek 的训练数据、隐藏状态或官方内部解释。现有公开证据支持"接口条件与轨迹变化相关"，但不足以从外部还原完整训练机制。 2.3 两侧的结构性弊端 • 短思维直觉：过早接受第一个流畅解释；复杂约束整合不足；跳过必要中间桥接；工具证据利用不足；局部测试成功后过早宣布完成。 • 长思维推理：分析惯性和行动延迟；反复推翻或重建已有判断；工具调用过晚；Token 与时间消耗增加；长程状态漂移；信息已经充分仍难以收束。 因此，二极管带来的主要工程问题不是某一侧必然更差，而是会话无法随任务阶段稳定调整推理形态：需要桥接时可能过快，需要行动时又可能持续推演。 三、三套方案的浅层关系 • Anchored Standard：作用于首次模型请求的接口条件。恢复已知的 Minimal 接口指纹，尽量让会话从入口进入并保持一条稳定轨迹。 • Routing Suite：作用于新会话开始前的任务分类与模式选择。根据任务选择较适合的稳定行为带，并回避不稳定过渡区域。 • J-Space：作用于会话进入轨迹后的完整任务生命周期。不宣称消除二极管，而是通过状态、行动、验证与恢复机制缓解会话落入任一侧后的结构性弊端。 三者可以被理解为入口恢复、入口选择和持续任务控制三个不同层面。这是一种便于工程使用的关系整理，不表示三套方案已经在统一 Harness 下完成组合实验，也不构成效果排名。 3.1 J-Space 对两侧弊端的浅层处理 当会话偏向短思维直觉时，J-Space 使用 bridge-before-conclusion、共享约束广播、Empirics、verifier 与 coverage，要求快速判断在交付前补足必要桥接、证据和验证范围。 当会话偏向长思维推理时，J-Space 使用功能性第一人称、明确的 Next、有限候选、差分测试与 checkpoint，把已经形成的判断绑定到行动、取证或收束，减少无新增约束的反复推演。 对于两种形态，Goal / Core / Verified / Open / Next 账本、工具接缝刷新与恢复机制负责维持跨文件、跨工具和长时间任务状态。这些机制调节外部任务过程，并不等同于让模型在同一会话中自由切换两种底层思维链。 四、Benchmark 记录 4.1 评测上下文 J-Space 在 DeepSeek 上的项目评测参照官方 Harness 极简模式。J-Space 通过工作空间路由、状态连续性、验证与恢复参与推理时流程。 结果形成于项目现有的评测环境。硬件条件、进程隔离、工具可用性与信息访问边界共同构成评测上下文；可访问资料及执行轨迹也可能影响观测结果。 以下汇总上述条件下的项目级 Benchmark 记录。其他模型的数据保留各厂商公开评测时的原有上下文，不同环境与 Harness 配置下出现分数变化属于正常现象。各 Benchmark 使用自身原生分数，数值越高越好；"—" 表示没有报告结果。 4.2 分数记录 顺序固定为：V4-Flash-0731 裸跑、V4-Flash-0731 + J-Space、V4-Pro-0813 裸跑、V4-Pro-0813 + J-Space、GLM-5.3、Kimi-K3、Opus-4.8、Fable 5（带 fallback）。 • HLE（无工具）：37.8、45.5、42.7、48.0、未报告、43.5、49.8、53.3（全场最高） • HLE（有工具）：51.5、60.6、60.0、67.7（全场最高）、62.5、56.0、57.9、63.0 • Terminal Bench 2.1：82.7、87.1、87.9、90.1（全场最高）、88.2、88.3、85.0、88.0 • NL2Repo：54.2、70.2、61.5、73.4（全场最高）、58.0、58.0、69.7、未报告 • CyberGym：76.7、81.7、83.3、86.8（全场最高）、84.5、80.0、78.3、83.1 • DeepSWE：54.4、67.4、62.7、72.0（全场最高）、66.9、67.5、58.0、70.0 • Toolathlon-Verified：70.3、77.7、74.1、79.5（全场最高）、73.0、76.5、76.2、77.9 • Agents' Last Exam：25.2、30.1、25.7、30.3（全场最高）、28.5、27.6、25.7、23.8 • AutomationBench（Public）：25.1、31.7、31.8、38.2、48.2（全场最高）、30.8、27.2、29.1 4.3 Benchmark 与二极管弊端的定性对应 • HLE（无工具）：短侧可能过早下结论，长侧可能在知识边界之外无效延伸；J-Space 对应必要桥接、置信控制与独立复核。 • HLE（有工具）、CyberGym：短侧可能少用或少整合证据，长侧可能迟迟不进入工具取证；对应 Empirics、工具接缝与验证覆盖。 • Terminal Bench：短侧可能快速执行但遗漏核验，长侧可能分析过度、行动延迟；对应明确的 Next、诊断重试与 checkpoint。 • NL2Repo、DeepSWE：短侧可能丢失跨文件约束，长侧可能反复重建计划；对应共享广播、Loop 账本与持续验证。 • Toolathlon-Verified：短侧可能跳过编排检查，长侧可能困在工具选择和重新规划；对应共享状态、接缝审计与 coverage。 • Agents' Last Exam、AutomationBench：异构任务或长间隔会放大固定路径与任务阶段的错配；对应选择性 pass、持久状态与恢复。 上述对应关系是工程解释，不是从分数反推出内部状态的证明。当前 Benchmark 记录没有逐次标注会话所处的二极管状态，因此不能据此计算二极管对分数的贡献比例，也不能把全部分数变化归因于单一机制。 4.4 数据来源 • DeepSeek V4-Flash-0731 模型卡： • 智谱 AI（ GLM-5.3 发布评测记录 • Kimi-K3 模型卡： • Claude Fable 5 与 Claude Mythos 5 System Card： • J-Space Cognition Suite V3.6 README： 五、适用边界 • 思维链二极管和极简接口过拟合属于黑盒工程诊断，不是 DeepSeek 官方披露的模型结构或训练事故。 • 词汇、首行风格和思维链长度只能作为轨迹探针，不能替代任务完成、工具行动、验证覆盖和得分。 • Anchored Standard、Routing Suite 与 J-Space 的关系是作用层面的整理，尚未经过统一组合实验验证。 • 当前分数是项目记录，不足以建立跨模型普遍性，也不支持精确的因果贡献分解。 • J-Space 不创造基础模型缺少的知识，也不保证对所有任务、模型或 Harness 产生正向变化。 引用：工程使用请引用 J-Space Cognition Suite V3.6（ 原文： #DeepSeek# #J-Space# #本地AI#

karavox 独立开发者 Łukasz Nowak 不信任任何 AI agent，他把安全保证直接建在令牌上：agent 物理上写不进生产仓库。 《我把 AI 编码 agent 当分包商》 引言 2026 年起，我开始用 AI agent 开发软件，主要是为了工作。一开始只有一个 agent，慢慢演化成更多。我试过各种方法，但没有一个真正契合我的工作流。 我对每一个 agent 都抱着不信任（坦白说，我找不到合适的英文词形容这种感觉——它是彻底的不信任，但又充满好奇，隐隐期待它们干出好活）。它们会犯错，我必须用令牌、用户和虚拟机给它们装上护栏。尽管如此，事实证明它们在我的工作里有用。我的 agent 运行在 YOLO 模式——改文件、提交、推送都不问问题，因为它们要对自己那一部分负责。 它在工作里开始生效。我们团队交付了能用的解决方案。我得以把一部分工作流外包给一个工具，自己专注于重要的事。它真的管用了…… ……这让我开始琢磨自己的业余项目——一个跟卡拉 OK 有关的东西。我可以手写代码，但为什么不用一群 agent 呢。经过大量来回拉扯，加上我本来就不怎么信任它们，最后我决定把它们当分包商对待。反正是我自己的项目，我可以多冒点险。 为什么是这个形态 我是一个独立开发者，有几个 agent 在一个小型生态里干活：一个开源格式和工具集、围绕它的闭源产品，以及支撑这一切的基础设施。塑造一切的约束很简单：我是瓶颈，我也是唯一有判断力的人。 Agent 能做很多事，但它们对我的事故史、我的边界情况、以及那些不存在于仓库里的运维约束一无所知。所以设计目标是：agent 可以在我缺席的情况下尽量多做——但它们永远碰不到我没看过的东西。 这个模型从哪来 这个模型不是我发明的。它始于一篇给这个角色命名的文章：Simon Willison 的 vibe engineering（2025-10-07）——AI 辅助开发里自律的一端，专业人士始终对软件负责，与之相对的是 vibe coding 快而松的一端。Willison 自己在 2026 年的更新里提到，最终胜出的叫法是 Agentic Engineering。随后的阅读塑造了剩下的部分： • Embracing the parallel coding agent lifestyle（Willison，2025-10-05）： ——并行 agent，审查带宽是瓶颈；研究/PoC 任务和规格严谨的工作属于安全类别。 • How I'm using coding agents in September, 2025（Jesse Vincent，2025-10-05）： ——架构师/实现者的分工，跨隔离的 git worktree，人类在他们之间当 PM。 • Best practices for using GitHub AI coding agents in production workflows?（GitHub Community，2025-12-17）： ——"AI agent 是强大的队友，不是自主提交者"：agent 提议代码，绝不拥有代码；只提草稿 PR；人在环内的合并契约。 第一层：令牌——agent 碰不到生产环境附近 每个 agent 拿到两个令牌。生产仓库上一个只读令牌，加上一个独立 -staging 仓库上的写令牌。任务分支直接从生产仓库的 main 分支切出来（只读权限就够做这件事），然后推到 staging 仓库——后者的存在纯粹是为了让写令牌有个能到达的地方。 Staging 仓库的默认分支是一个故意的墓碑，名字就叫 no-main，里面只有一个 README："请使用原仓库的 main 分支。" 没有任何东西合并进它。没有任何东西同步它。它没有历史，没有镜像，除了当 agent 的邮箱之外没有任何意义。 为什么不用标准工具？因为在我的套餐里它们不存在：GitHub 的文档写明，受保护分支在免费套餐里只对公开仓库开放，私有仓库要从 Pro 起；把私有仓库 fork 到组织里也需要 GitHub Team，不是 Free。令牌作用域是唯一能在物理上阻止 agent 碰生产环境的机制——所以这个设计把保障建立在令牌上，而不是设置上。 第二层：集成——我就是 merge bot 当一个分支就绪时，agent 告诉我。我把它取回来，审查 diff，然后以任何合适的方式合并进来：cherry-pick、rebase-merge，或者手工应用。没有 pull request 机制，没有 agent 写的合并提交，没有积压着没人读的 PR。 这是一个穿了新衣服的老模式。Git 自己的文档把它描述为集成经理工作流（integration-manager workflow）：没有写权限的贡献者提交补丁，维护者负责应用。这正是我在做的事——我的 agent 是补丁贡献者，staging 仓库是它们的邮箱。这是 Linux 内核用了二十年的模型，只是把邮件 diff 换成了分支。 一条规则让这件事保持诚实：一个分支在独立验证它确实在生产里之前，绝不删除（对生产默认分支跑 git merge-base --is-ancestor，如果提交被 squash 过，就跑等价检查）。可检查胜过口头保证——包括我自己的口头保证。 第三层：PR 政策——判断，不是教条 公开仓库 karavox 只接受 PR。这没得商量：它是开源的，面对未知贡献者，PR 是那里的贡献规范。 私有仓库由我自行判断。为什么这说得通？因为审查无论如何都会发生——问题只是发生在哪一层。在 PR 模型里，审查是 GitHub 强制执行的一种仪式；在我的模型里，审查就是集成本身。对一个身兼 QA 的独立集成者来说，pull request 是开销，审查不是。我从不跳过审查——我跳过的是仪式。 各厂商正在向同样的原则靠拢。Claude Code 的安全文档：手动模式下它以只读权限启动，并且"你有责任审查提议的代码"。OpenAI Codex 的文档：默认沙箱化，带审批策略——Codex 执行动作前必须询问。GitHub 自己的 agentic workflow 工具 gh-aw：agent 作业默认只读且沙箱化，写入通过经过验证的 safe-outputs 作业和受限权限应用。GitHub 自己的社区指南说得更直白："AI agent 可以提议代码，绝不拥有代码。" 整个行业都在向我这一边收敛——只是大多数人还没有走到删除 staging 镜像那一步。 实战故事：那个死掉的模型 墓碑不是最初的设计。一开始 staging 仓库在一条名字就叫 staging 的分支上保存了生产环境的完整镜像：任务分支从镜像切出，合并进 staging，然后晋升到生产。这个模型要求两样东西靠约定保持同步——镜像，以及 staging 分支本身。2026-08-14 它真的漂移了：两个分支直接落到了生产 main 上，而 staging 落后了两个提交。 修复不是加固同步。修复是删除镜像。任务分支现在直接基于生产环境自己的历史，于是没有任何东西需要保持同步了。staging 仓库当天下午就变成了墓碑，从那以后工作流一直更简单。一个在生产中死掉的治理模型是一个好治理模型——它证明了自己可以被重新设计，而不是打补丁。 别人在做什么 • Fork + pull request，维护者合并：GitHub 文档——fork 是一个独立的仓库，有自己的设置，与上游相连；私有仓库可以 fork 到个人账户，但 fork 到组织需要 GitHub Team。 • 同一仓库上分支保护 + 必需审查：GitHub 文档——受保护分支对公开仓库免费；私有仓库需要 Pro、Team 或 Enterprise。 • 补丁邮件（git format-patch）：Git 官方书——记载了集成经理工作流：没有写权限的贡献者提交补丁，维护者应用它们。 • 自动化验证-合并（agent 写，验证者合并）：GitHub 的 agentic workflow 工具 gh-aw——agent 作业默认只读且沙箱化，写入通过经过验证的 safe-outputs 作业和受限权限应用。 这给我换来了什么 • Agent 做完所有判断开始之前的事。 • 我只在值得的地方花注意力——每一次集成按定义就是一次审查。 • 没有要分诊的 PR 队列，没有机器写的合并提交，没有仪式。 • 公开仓库保留贡献规范；私有仓库保留速度。 诚实的局限 生产 main 本身只靠令牌作用域加上我的纪律来保护——分支保护会是双保险，但在我的套餐里它不可用。而且行业信号很清楚：GitHub 上超过五分之一的代码审查现在有 agent 参与。判断力是瓶颈，这个模型正是围绕这个事实构建的，而不是假装瓶颈不存在。 来源： GitHub 文档（受保护分支、fork）；Git Pro book（为项目做贡献）；Claude Code 安全文档；OpenAI Codex agent 审批与安全；GitHub Agentic Workflows（gh-aw）；GitHub Community AI 编码 agent 最佳实践；GitHub 博客 agent pull requests。 原文： #AIAgent# #AgenticEngineering# #工作流#

Django 共同创造者 Simon Willison 从 2023 年 5 月就开始跟踪 Mojo 的开源承诺。今天它兑现了，但这门语言已经不是承诺里的「Python 超集」，官方一年前就放弃了。 《Mojo🔥 开源了》 Mojo 编程语言从 2023 年 5 月起就一直在承诺开源。上周他们发布了 1.0，今天他们兑现了最初的承诺：编译器和工具链以 Apache 2 许可证发布。 Mojo 刚推出时的既定目标，是做一个 Python 的超集，让现有的 Python 代码可以用来启动他们自己的生态。这个计划在 2025 年 8 月前后变了： Mojo 可能演化成 Python 的完整超集，也可能不会，没成也没关系。 AI 辅助编程工具现在已能把 Python 迁移到 Mojo，而且效果很好，这让我们很受鼓舞。我们相信，随着未来工具和生态的成熟，这个演化会走得更顺。 今天的 Mojo 是它自己的语言，用受 Python 启发的语法，把 GPU 编程做得尽可能无痛，虽然与现有代码不是 100% 兼容。 原文： #Mojo# #开源# #GPU编程#

投机解码的 drafter 从来都是一个 token 一个 token 地猜。做出 DFlash 的推理公司 Inco AI 说这没必要：正确的 token 本来就在候选列表里，整块并行预测之后挑出一条连贯路径，输出不变，每次验证多赚一个完整的 token。 《DFlash 2：保持并行起草》 推理是 agent 时代的瓶颈。agent 会读、会规划、会调用工具，常常一跑就是几小时甚至几天。它们消耗 token 的速度，是聊天场景从未达到过的。而每一个 token 都要在模型上跑一次完整的前向传播。在 Inco AI，我们在构建一套面向未来 token 经济学的推理栈。这篇文章是一次预览。 我们的团队 1 月发布了 DFlash（论文： SGLang、vLLM、TensorRT-LLM 和 llama.cpp 里。NVIDIA 在 Blackwell GPU 上用它测到了最高 15 倍的吞吐；Google 报告在 TPU 上每秒 token 数提升 3 倍；CoreWeave 生产环境的 Kimi K2.7 Code 端点（Artificial Analysis 上该模型最快的端点）默认就跑 DFlash。生态已经在它之上构建：NVIDIA、Red Hat、Modal 都发布了 DFlash drafter；Meta（Muse Glimmer）、Poolside（Laguna）、小米（MiMo-V2.5-Pro）、NVIDIA（Nemotron 3.5 Lightning）随自家模型发布官方 drafter。在 Hugging Face 上，DFlash 模型被下载了超过 350 万次（截至 2026 年 8 月）。 投机解码是现代推理栈的核心组件之一。一个小 drafter 模型猜出一整块 token，目标模型在一次前向传播里验证整块。猜得好，一次前向变成多个 token；猜得差，丢掉重来。但多年来，起草本身一直是自回归的：一次一个 token。DFlash 让它也变成了一次通过：整块、每个位置，并行预测。 （演示视频：DFlash 2 在 Apple M5 Max 上用 oMLX 为 Qwen3.8-27B 起草，与自回归解码并排对比。 DFlash 2 把并行起草又往前推了一步：每次验证通过多产出 20% 以上的输出，增加的周期延迟只有约 1%，而输出可证明不变。跨基准测试的增益在 16–25%。配合今天发布的 Qwen3.8-27B drafter，SGLang 在 batch size 1 下达到自回归解码 2.7–3.4 倍的吞吐。每个位置独立预测，留下两处空间：选对 token，以及在块的末尾守住准确率。DFlash 2 把这两处都拿了回来，同时没有放弃一次性通过的设计。 现在就能跑 DFlash 2 已经跑在主流推理引擎里。 SGLang： pip install -U "sglang[all] @ git+" python -m sglang.launch_server \ --model-path Qwen/Qwen3.8-27B \ --speculative-algorithm DFLASH \ --speculative-draft-model-path incoai/Qwen3.8-27B-DFlash2 \ --speculative-num-draft-tokens 8 vLLM： pip install -U "vllm @ git+" vllm serve Qwen/Qwen3.8-27B \ --speculative-config '{ "method": "dflash", "model": "incoai/Qwen3.8-27B-DFlash2", "num_speculative_tokens": 7 }' llama.cpp： git clone cd llama.cpp git fetch origin pull/27342/head:pr-27342 git switch pr-27342 NVIDIA CUDA cmake -B build -DCMAKE_BUILD_TYPE=Release -DGGML_CUDA=ON cmake --build build -j Apple Silicon cmake -B build -DCMAKE_BUILD_TYPE=Release -DGGML_METAL=ON cmake --build build -j ./build/bin/llama-server \ -hf ggml-org/Qwen3.8-27B-GGUF:Q4_K_M \ -hfd incoai/Qwen3.8-27B-DFlash2-GGUF:Q4_K_M \ --spec-type draft-dflash \ --spec-draft-n-max 7 oMLX：下载安装支持 DFlash 2 的预构建版（ 在 oMLX 里跑 Qwen3.8-27B 加 DFlash 2： 1. 打开 oMLX 的 Model Downloader，下载 mlx-community/Qwen3.8-27B-4bit 和 incoai/Qwen3.8-27B-DFlash2。 2. 打开 Model Manager，编辑 mlx-community/Qwen3.8-27B-4bit，配置 DFlash： • DFlash：enabled • Draft model：incoai/Qwen3.8-27B-DFlash2 • Draft quantization：enabled • Runtime block size：5 • Verify mode：dflash 3. 保存设置，加载目标模型。 对的 token 早就在候选里 DFlash 每个位置独立、并行地预测。每个选择单独看都合理，但没有什么让它们彼此咬合，一个不连贯的块会在验证时被截断。近期的方法如 Domino 和 DSpark，用顺序的 Markov head 重写每个位置的完整词表分布来买连贯性。但真的需要这种昂贵的自回归纠错吗？ 不需要。证据就在 DFlash 自己的候选列表里。拿第一个位置来说：DFlash 的第一选择 85.4% 的情况下是对的，但正确的 token 99.5% 的情况下都在前 16 个候选里。即使第一选择错了，对的 token 通常也在列表上。 表 1：Recall@1（第一选择正确的概率）与 Recall@16（正确 token 出现在前 16 候选里的概率），按起草位置统计，条件是前面每个位置都正确。GSM8K 上的五层 Qwen3-4B DFlash。接受长度包含验证器产出的下一个 token。 • 位置 0：Recall@1 85.4%，Recall@16 99.5% • 位置 1：80.3%，97.3% • 位置 2：79.4%，94.8% • 位置 3：78.3%，92.6% • 位置 4：77.5%，90.8% • 位置 5：75.9%，89.4% • 位置 6：72.9%，87.8% • 接受长度：4.27（只看第一选择）；6.79（从前 16 里选） 一个总能从前 16 个候选里挑对的那个 oracle，会把接受长度从 4.27 抬到 6.79。这个差距是纯粹的选择空间。我们只需要在候选里选出一条正确的路径。 图 1：一个周期里的选择器。只用 DFlash，每个位置保留自己的第一选择；这里两个相邻位置选了同一个词，结巴在验证时死掉。DFlash 2 保留每个位置的 top 候选，选择器在候选之间走出一条连贯路径；这里整块都活了下来。 一个轻量的路径选择器 连贯性大体是局部的：一个候选合不合适，主要取决于它前面的那个 token，所以给相邻对打分应该就够了。DFlash 2 保留每个位置前 16 个候选，给每一对相邻候选打分。对前一个 token a 和当前候选 b： S_t(a,b) = U_t(b) + ⟨A(a)⊙H(h_t), B(b)⟩ 分数分两部分。第一部分 U_t(b) 是 DFlash 自己的 logit：drafter 本身有多喜欢 b。第二部分问 b 接在 a 后面有多顺：A 和 B 给每个 token 一个紧凑的 256 维嵌入，两个嵌入在一个上下文门控 H(h_t) 下匹配，门控决定匹配的哪些部分算数。本质上，这是对相邻候选做的低秩双线性注意力。 打分全程并行。每个位置的每一对相邻候选一次性全部算完，不需要额外的 backbone 或 LM head 前向。唯一串行的部分，是最后在预计算好的分数上走一遍：从最后一个已验证 token 出发，贪心地跟着每一步最好的后继走，采样从同样的分数里抽取，拒绝采样恢复出精确的目标分布。 表 2：只加路径选择（不加卷积）的接受长度，GSM8K 上的五层 Qwen3-4B。开销相对纯 DFlash：drafter 增加的参数、起草-验证周期增加的延迟。 • DFlash：T=0 下 4.27，T=1 下 3.78 • + DSpark 纠错：+77.8M 参数，+9.6% 延迟；4.49，4.08 • + 路径选择（我们的）：+2.0M 参数，+0.6% 延迟；4.61，4.25 选择器在 T=0 下给 DFlash 加 0.34 个 token，T=1 下加 0.47。两个设置下都超过 DSpark 的纠错，参数少约 40 倍，延迟开销低 16 倍。选择比预测便宜。而且还有空间：oracle 能到 6.79。成对打分是我们能想到的最简单的选择器，我们相信这里还有很多可探索的。 后缀衰减是个局部问题 我们还注意到上面两行 recall 都在块尾下滑。连 oracle 都在衰减：即使选择完美，准确率仍然从第一个位置的 99.5% 掉到最后一个位置的 87.8%。没有选择器能修这个，因为候选自己就不够了。我们把这个叫后缀衰减，它是 backbone 的问题。 一个嫌疑是容量：五层 backbone 可能太小，撑不住横跨整块的依赖。如果真是这样，深度应该在靠后的位置帮上最多的忙。事实也如此：3 层、5 层、15 层的 DFlash 模型在第一个位置上几乎一样，越往块尾分得越开。但深度不加区分：多十层 attention block 到处加容量，连那些没什么可赚的靠前位置也加，把 DFlash 吸引人的那部分效率磨掉了。 图 2：GSM8K 上 Qwen3-4B 的 Recall@1（T=0），条件是前面每个位置都正确。所有 drafter 在相同设置下训练；卷积模型评估时不带选择器。它的卷积增加 3% 参数和 0.7% 周期延迟；15 层模型多出的十层增加 15.2%。 我们要一个有针对性的修法，而 DFlash 的 attention 指出了修哪里。它有两份工作：读块之前的上下文，以及建模块内部的依赖。但它在第二份上花的越来越少：块内注意力占比从第 1 层的 30% 掉到第 5 层的 8%，剩下的还集中在越来越少的一小撮 head 里。所以我们把两份工作拆开：一个专用模块承担块内工作，attention 继续读上下文。 图 3：五层 Qwen3-4B DFlash 的块内注意力按 head 分布。越亮的格子代表在起草块上花注意力越多的 head；靠后的层里，块内质量收缩、集中到少数几个 head。 一个轻量的局部卷积 块内工作本来就是短程的：一个块只有 4 到 16 个 token，最紧的依赖坐在相邻位置之间。自然的算子是短卷积：两个抽头，一个在当前位置，一个够到前一个位置，权重随内容自适应。跟随 Canon Layers、Dynamic Short Convolutions 和 Convolution for Large Language Models 的做法，我们在每个 attention 和 feed-forward 子层前后插入这个双抽头动态深度卷积： Conv_k(x)_t = k_{t,0}⊙x_t + k_{t,1}⊙x_{t-1} 每个系数由一个可学习的基核加上从当前隐藏状态算出的一个小修正组成；每 16 个通道共享一个修正。第一个位置读最后一个已验证 token 的表示，之后的每个位置读它前一个的。信息穿过整块，同时所有位置仍然并行计算。 图 4：双抽头动态卷积。每个 drafter 层的每个 attention 和 MLP 子层前后各有一个。内部：每个位置把自己的表示和前一个的混合；第一个位置读最后一个已验证 token。 卷积是块局部的、无状态的，所以能无缝插进 DFlash，不用动 attention、LM head 或验证。 只加 16.5M 参数（3%），带卷积的五层 DFlash 就逼近了 15 层 DFlash，大幅减轻后缀衰减。卷积给起草-验证周期延迟加 0.7%；多十层 Transformer 层加 15.2%。第 4、5 层的平均块内注意力从 9.4% 降到 0.5%，与卷积吸收局部工作、attention 回到读上下文一致。一个只够到前一个位置的核，买回了十层额外层的大部分收益：后缀衰减大体是个局部问题。 合在一起 到目前为止，选择器和卷积是分开测的；下面的完整对比把它们放在一起。DFlash 和 DSpark drafter 是我们在对齐的设置下自己训练的，MTP 随模型发布。 表 3：Qwen3.5-4B 每请求平均接受长度。采样：thinking 开启，温度 1.0，top-p 0.95，top-k 20，presence penalty 1.5，无损拒绝采样。 • GSM8K：MTP 4.78，DFlash 4.99，DSpark 5.69，DFlash 2 6.20 • MATH-500：5.04，5.42，6.20，6.76 • HumanEval：4.84，5.43，5.80，6.28 • MBPP：4.16，4.49，4.96，5.41 • MT-Bench：3.90，4.26，4.77，5.20 • 平均：4.54，4.92，5.49，5.97 DFlash 2 在每项基准上都领先。平均下来，它比 DFlash 多 1.05 个 token（21%），比 DSpark 多 0.48。升级仍然便宜：选择器和卷积加起来，只给五层 DFlash 的起草-验证周期延迟加了 1.3%。 在 MATH-500 上，增益逐位置可见：DFlash 2 到最后一个位置都稳在 86% 附近，而每个基线在块尾都比它低 6 到 9 个点。 图 5：MATH-500 上 Qwen3.5-4B 的条件接受率，采样同上。 两个 drafter，今天发布 我们今天发布两个 DFlash 2 drafter：一个给 Qwen3.8-27B（ Meta 的 Muse Glimmer（ Qwen3.8-27B，我们对比模型原生的 MTP 路径和一个社区 DSpark drafter。 表 4：Qwen3.8-27B 每请求平均接受长度，模型默认采样、块大小 8，对比原生 MTP 路径和社区 DSpark drafter。 • GSM8K：MTP 5.02，DSpark 4.36，DFlash 2 5.46 • MATH-500：4.72，3.92，5.28 • HumanEval：3.91，3.30，4.39 • MBPP：3.99，3.51，4.79 • MT-Bench：3.74，3.01，4.10 • 平均：4.28，3.62，4.80 对 Meta 的 Muse Glimmer，我们对比随模型发布的官方 DFlash drafter 和一个社区 DSpark drafter。 表 5：Muse Glimmer 每请求平均接受长度，模型默认采样、块大小 16。DFlash 是 Meta 随模型发布的官方 drafter；DSpark 是社区 drafter。 • GSM8K：DFlash 5.43，DSpark 5.45，DFlash 2 6.57 • MATH-500：5.39，5.01，6.56 • HumanEval：4.11，4.33，5.66 • MBPP：3.74，4.02，5.30 • MT-Bench：3.52，3.59，4.42 • 平均：4.44，4.48，5.70 差距很大：在两个模型上，DFlash 2 平均比 DSpark 多出超过一个完整的 token。它也超过每个模型的官方 drafter：Qwen3.8-27B 的 MTP、Muse Glimmer 的 DFlash。换算成吞吐，Qwen3.8-27B 上达到自回归解码的 2.7–3.4 倍，Muse Glimmer 上 3.1–4.6 倍。模型卡（ 底线 agent 一个下午写出来的东西，聊天机器人要写一个月，而每一个 token 底下都坐着解码。DFlash 2 以接近自回归解码 3 倍的速度解码，每个 token 约三分之一的算力，输出相同。 七个月里，DFlash 从我们的论文变成了行业标准，超过 350 万次下载。在同一个设计内部，DFlash 2 每次通过多解码一个完整的 token，免费。那还只是服务栈的一个组件。推理离它的地板还很远。 在 Inco AI，我们在构建一套端到端的服务栈，把这个地板继续往下压。DFlash 2 是第一块。两个 drafter 今天发布在 Hugging Face。 如果你在规模化地服务 agent，想在你的栈里评估 DFlash 2，或者想为你跑的模型（包括你自己的微调）要一个 drafter，写信给我们：contact@inco.ai。 我们也在招人。如果你想一起构建这套栈，联系我们。 把候选连起来。起草，继续并行。 脚注：Modal 的 Speculation Is All You Need 指出，投机解码是对低延迟服务最重要的优化。我们是他们工作的超级粉丝，感谢他们自 DFlash 发布以来的支持和讨论。 本文引用格式：@misc{inco2026dflash2, title={DFlash 2: Keep Drafting Parallel}, year={2026}, month={August}, url={ 原文： #DFlash# #投机解码# #LLM推理#

Claude Fable 5 是 DeepSWE 记分板上最贵的模型。Together AI 拿它跟全场最便宜的模型各跑了 452 次，给出的用法建议是反过来：贵的当后手。 《DeepSWE 上的 DeepSeek V4 Pro 0813 vs Claude Fable 5：成本、编码与路由》 DeepSWE 上的 DeepSeek V4 Pro 0813 vs Claude Fable 5：成本、编码和路由 要点 • 先跑 DeepSeek V4 Pro 0813，只有它失败时才升级到 Claude Fable 5。这条级联链解决 82.7% 的 DeepSWE 任务，每个任务 8.28 美元。单用 Fable 是 69.7%、每个任务 21.63 美元。高 13 个百分点，便宜 62%。 • Fable 赢第一发。pass@1 69.7% 对 62.8%，领先 7 个点。 • Pro 赢之后每一发。pass@2 打平（78.5% 对 77.1%），pass@4 领先（88.5% 对 84.1%）。 • 价格差 90 倍。每次 rollout 0.24 美元对 21.63 美元。每花 100 美元，Pro 解决 260 个任务，Fable 解决 3 个。 • 它们栽在不同的任务上。逐任务相关性只有 0.39，是我们测过的分歧最大的一对。两者合计覆盖 113 个任务中的 107 个。分歧正是路由能成立的全部理由。 现已上线 · 美国托管：在 Together AI 上运行 DeepSeek-V4 Pro 0813——1.05M 上下文，支持 function calling 和 JSON mode，OpenAI 兼容 API，托管在美国基础设施。查看模型 在我们对 DeepSeek V4 Pro 0813 与 Claude Fable 5 的 DeepSWE 对比中——DeepSWE 是一个跨多种任务类型和编程语言测试模型软件工程能力的基准——这两个模型坐在价格表的两端。Claude Fable 5 的每次 rollout 是 DeepSWE 全榜最贵。DeepSeek V4 Pro 0813 是最便宜的之一。Fable 首发的准确率高 7 个百分点，单次 rollout 却贵 90 倍，所以真正的问题不是哪个模型更好，而是这 90 倍的溢价到底买到了什么、什么时候值得付。 DeepSWE · 正面对决 DeepSeek V4 Pro 0813 vs Claude Fable 5 一览 • claude-fable-5 [max]：pass@1 69.7% ± 2.3%，平均成本 21.63 美元，每 100 美元解决 3 个任务，输出 token 115k，79 步 • deepseek-v4-pro-0813 [max]：pass@1 62.8% ± 3.1%，平均成本 0.24 美元，每 100 美元解决 260 个任务，输出 token 101k，146 步 我们在全部 113 个 DeepSWE 任务上，用 DeepSeek V4 Pro 0813（max）对 Claude Fable 5（max）各跑四次 trial，取自已发布的逐 trial 记录：总计 904 次 rollout（各 452 次）。Fable 是贵价的手艺人；Pro 是性价比上的异类。这两个模型的分歧也大于这套数据里的任何其他组合——结果这成了它们最有趣的地方。下文的每个数字都来自本次运行，所以可能与其他公开的 DeepSeek V4 Pro 0813 vs Claude Fable 5 记分卡有出入。 DeepSWE 记分板：pass@1 与 pass@k 单发，Fable 领先：pass@1 69.7% 对 Pro 的 62.8%（官方计分）。但这个领先很脆弱。两次尝试时 Pro 追平（78.5 对 77.1），四次尝试时 Pro 的 pass@4 88.5% 比 Fable 的 84.1% 高出 4 个多百分点。对一个贵 90 倍的模型来说，Fable 既没有守住天花板，也没有在重试下保住首发优势。更便宜的模型覆盖更广，best-of-k 也更高。 成本对比：DeepSeek V4 Pro 0813 vs Claude Fable 5 的价格 每次 rollout 0.24 美元，DeepSeek V4 Pro 0813 比 Fable（21.63 美元）便宜 90 倍：每 100 美元解决 260 个任务，Fable 只有 3 个。这是我们测过的所有组合里最宽的成本差距，Fable 也是榜单上最贵的单个配置。而且与直觉相反，低价格没有带来速度惩罚：Fable 的中位 rollout 31 分钟，Pro 35 分钟，基本持平——因为 Fable 是榜单上话最多的模型（115k 输出 token），尽管它的步数更少（79 对 146）。Pro 走的步数多；Fable 每步写得多。两个模型谁也没有明显更快。 失败模式：两个模型分别怎么错 两者在「不破坏东西」上都算自律：DeepSeek V4 Pro 0813 和 Fable 各自只在 11% 的失败里回归了现有测试套件，远低于 GPT 家族的 20%。差别在另一个方向：Fable 的大偏差失误占比是这里最高的（18% 对 Pro 的 10%），也就是说 Fable 一旦错，更常是错得离谱——给出离题很远的方案，而不是差一个边界用例。Pro 更多时候倒在离正确答案不远的地方（66% 的近似失手，对 Fable 的 57%）。所以两者都可以不加重度回归门禁就放心接入，但 Fable 的失手是调试成本更高的那种。 按任务类型，各自赢在哪 Fable 的手艺体现在推理重、契约精确的领域：8 个领域里它赢 6 个，领头的是数据建模与序列化（88%，比 Pro 高 24 个点）和语言内部机制（78）。但 DeepSeek V4 Pro 0813 拿下两个，两个都分量不轻：有状态响应式（66 对 64），以及——更有说服力的——并发与持久化（58 对 45）：在恰恰是 Fable 最弱的领域里领先 13 个点。Fable 在并发上的 45% 是它最弱的格子，也是唯一一个便宜模型不只是更便宜、而是工程师水平更高的领域。 按编程语言 Fable 赢下五种语言里的四种，但真正对得起它价格的是 Rust：85% 对 Pro 的 65%，20 个点的差距，也是这场对决里最大的一处差距。Fable 显然是序列化和 Rust 专家。其他语言都比价格暗示的接近（Python 70 对 60，Go 71 对 67，JavaScript 75 对 65），DeepSeek V4 Pro 0813 则实际拿下 TypeScript（61 对 57）。Rust 和序列化之外，付 90 倍价格的理由很难成立。 这两个模型到底有多不一样？ 亮点在这里。逐任务相关性只有 0.39，是我们测过的 DeepSeek-Pro 组合里最低的——这两个模型是真心意见不合。它们各自解决了 88 个任务；Pro 单独拿下 12 个，Fable 单独拿下 7 个，只有 6 个任务两边都栽。两者的并集覆盖 113 个任务中的 107 个（94.7%），而且分歧是双向的：DeepSeek V4 Pro 0813 在 awilix-async-container-initialization 上四发四中，Fable 一次没成；Fable 在四个 Pro 全挂的任务上四发四中（包括 koota-query-predicates 和 testem-bail-on-test-failure）。这是真正的互补，不是冗余。 在两者之间路由：组合打法 多样性加上价格差，让级联变得很划算。先跑 DeepSeek V4 Pro 0813，只有测试套件否决答案时才升级到 Fable：82.7% 的解决率，每个任务 8.28 美元。比单用 Fable（69.7%）高 13 个百分点，价格不到 Fable 单任务价格（21.63 美元）的一半。廉价的第一阶段清掉大部分队列，Fable 的溢价只花在难啃的剩余任务上，而且那些任务在上面还多获得一次独立的尝试。级联甚至赢过完美的一次性 oracle 路由（78.8%）。顺序不是可选项：Pro 先行每个任务 8.28 美元，Fable 先行 21.71 美元，准确率一样。 这意味着什么 Fable 5 是这张榜单上最难被当作默认模型的：最贵的一次 rollout 遥遥领先，首发优势被重试抹平，四发也没有天花板优势。只为两件事买它：Rust（85%）和序列化密集的工作（88%）——只有在这里它的质量才真正对得起价格。 DeepSeek V4 Pro 0813 是相反的画像：首发准确率接近 Fable，天花板更高，失败画像持平或更好，便宜 90 倍——尽管它在 Rust 和契约精确的领域让位。而因为两者是我们测过最多样的一对，Fable 最好的用法不是当默认，而是躲在低成本的 Pro 第一阶段后面做选择性升级，只在那少数真需要 Rust 或序列化专家的任务上付费。 现已上线 · 美国托管：在 Together AI 上运行 DeepSeek-V4 Pro 0813——1.05M 上下文，支持 function calling 和 JSON mode，OpenAI 兼容 API，托管在美国基础设施。查看模型 数据表：DeepSeek V4 Pro 0813 vs Claude Fable 5 完整结果 DeepSWE · 完整结果 • Pass@1（官方计分）：Pro 62.8%，Fable 69.7% • Pass@1（错误计为失败）：62.8%，67.3% • Pass@2 / pass@4：78.5 / 88.5%，77.1 / 84.1% • 覆盖率 / 可靠性：88.5 / 71.0%，84.1 / 82.0% • 四发四中 / 全挂：35 / 13，56 / 18 • 每次 rollout 成本 / 总成本：0.24 美元 / 109 美元，21.63 美元 / 9,346 美元 • 每 100 美元解决数：261，3 • 中位分钟 / 步数：35 / 146，31 / 79 • 中位峰值上下文 / 输出 token：232k / 101k，202k / 115k • 失败构成（近似 / 大偏差 / 回归）：66% / 10% / 11%，57% / 18% / 11% • 赢下的领域（共 8 个）：2（有状态、并发），6 • 赢下的语言：1（TypeScript），4（Rust 大胜） • 逐任务相关性 / 并集（两模型合计）：0.39 / 113 中的 107（94.7%） • Pro → Fable 级联（准确率 / 成本）：82.7% / 8.28 美元（单用 Fable 69.7% / 21.63 美元） • 单发 oracle 路由：78.8% • 基础设施错误：0，16 FAQ DeepSeek V4 Pro 0813 比 Claude Fable 5 更好吗？ 看指标。Claude Fable 5 赢 DeepSWE 上的单次尝试质量（pass@1 69.7% 对 62.8%），四发四中的任务也更多（56 对 35）。DeepSeek V4 Pro 0813 在 pass@2 追平、pass@4 反超（88.5% 对 84.1%），且每次 rollout 便宜 90 倍，所以在大批量或容忍重试的 agent 工作里，它是更强的性价比之选。 DeepSeek V4 Pro 0813 比 Claude Fable 5 便宜多少？ 在我们的运行里，DeepSeek V4 Pro 0813 每次 rollout 0.24 美元，Claude Fable 5 满血档 21.63 美元，约便宜 90 倍。按解决的任务算，Pro 每 100 美元解决 260 个，Fable 是 3 个——每美元的产出大约差 80 倍。 编码该用 DeepSeek V4 Pro 0813 还是 Claude Fable 5？ 大多数编码工作，两者的差距比价格暗示的小。Claude Fable 5 领先 Rust（85 对 65）、Python、Go 和 JavaScript，赢下 8 个领域中的 6 个，领头的是数据建模与序列化。DeepSeek V4 Pro 0813 拿下 TypeScript（61 对 57）、有状态响应式，以及并发与持久化（58 对 45）——那正是 Fable 最弱的领域。 要不要在 DeepSeek V4 Pro 0813 和 Claude Fable 5 之间做路由？ 要，前提是你能验证结果。两者是我们测过的所有组合里逐任务相关性最低的（0.39），合计覆盖 113 个任务中的 107 个。先跑 DeepSeek V4 Pro 0813，当测试套件否决输出时升级到 Claude Fable 5，能达到 82.7%、每个任务 8.28 美元——赢过单用 Fable，也赢过完美的一次性 oracle 路由。 DeepSWE 的 pass@k 是什么？ pass@k 衡量一个任务在 k 次尝试中是否至少有一次通过隐藏测试套件。pass@1 奖励一次做对；更高的 k 奖励能在多次尝试后最终到达方案的模型。DeepSeek V4 Pro 0813 的优势随 k 增大而扩大。 原文： #DeepSWE# #AI编程# #LLM评测#

推荐这个工具，autoresearch——一个 Claude Code skill。 把 Karpathy 的 630 行 Python 自主实验脚本泛化成了 14 个命令的通用 agent 循环：你给一个目标和指标，它自主迭代到完成为止。 核心循环 LOOP (N 轮或直到完成): 1. 审视当前状态 + git 历史 + 结果日志 2. 选择下一个改动（基于之前什么有效、什么失败、什么还没试） 3. 做一次聚焦的改动 4. Git commit（验证之前先提交） 5. 运行机械验证（测试、benchmark、分数） 6. 如果改进 → 保留。如果变差 → git revert。如果崩溃 → 修复或跳过。 7. 记录结果 8. 重复 每次改进叠加。每次失败自动回滚。进度记录为 TSV 格式。 v2.2.0 新增：自主编排器 不再需要手动设置 Goal / Metric / Verify。直接输入一个自然语言目标，编排器自动分类目标、推导 Success 谓词、与你确认一次，然后在 14 个子命令之间自主编排，直到完成。 14 个命令 | 命令 | 用途 | |------|------| | /autoresearch | 核心迭代循环，或自主编排模式 | | /autoresearch:plan | 把目标转化为验证过的配置 | | /autoresearch:debug | 假设驱动的自主 bug 猎手 | | /autoresearch:fix | 逐个击破错误直到归零 | | /autoresearch:security | STRIDE + OWASP 安全审计 | | /autoresearch:ship | 8 阶段通用发布工作流 | | /autoresearch:scenario | 12 个维度的边缘案例探索 | | /autoresearch:predict | 5 个专家角色辩论预测 | | /autoresearch:learn | 自主文档生成引擎 | | /autoresearch:reason | 对抗性辩论精炼（盲审团裁定） | | /autoresearch:probe | 8 个角色对抗性需求审问 | | /autoresearch:improve | 产品改进研究 + PRD 生成 | | /autoresearch:evals | 结果分析：趋势、平台期、收敛信号 | | /autoresearch:regression | 稳定性门禁：baseline vs candidate → STABLE/UNSTABLE | 另有 Guard 机制：在优化某个指标时设置"这个命令必须始终通过"的安全网。 安装 npx skills add uditgoenka/autoresearch 然后重启 Claude Code，14 个命令全部可用。通过 /plugin update autoresearch 升级。 v2.1 架构重写 原来的 SKILL.md 是一个 813 行的单体文件，每次调用消耗约 100K token。v2.1 把它拆成了一个 41 行的路由文件 + 12 个自包含命令文件（每个 94-120 行，每次调用约 5-8K token）。相同功能面，token 减少 95%。 9 个安全 hook 默认全部启用，可单独关闭。覆盖：阻止 node_modules 等目录进入上下文、阻止读取 .env/SSH 密钥、阻止 force-push/rm -rf、压缩后重新注入上下文、子 agent 状态感知等。 GitHub： 参考： #ClaudeCode# #Skill# #AgentLoop#

推荐这个工具，autoresearch——一个 Claude Code skill。 把 Karpathy 的 630 行 Python 自主实验脚本泛化成了 14 个命令的通用 agent 循环：你给一个目标和指标，它自主迭代到完成为止。 autoresearch 是一个 Claude Code skill，把 Karpathy 的 autoresearch 概念（一个 630 行的 Python 脚本，能自主跑通宵 ML 实验）泛化到了任意领域。支持 Claude Code、OpenCode 和 OpenAI Codex。MIT 开源。 核心循环 LOOP (N 轮或直到完成): 1. 审视当前状态 + git 历史 + 结果日志 2. 选择下一个改动（基于之前什么有效、什么失败、什么还没试） 3. 做一次聚焦的改动 4. Git commit（验证之前先提交） 5. 运行机械验证（测试、benchmark、分数） 6. 如果改进 → 保留。如果变差 → git revert。如果崩溃 → 修复或跳过。 7. 记录结果 8. 重复 每次改进叠加。每次失败自动回滚。进度记录为 TSV 格式。 v2.2.0 新增：自主编排器 不再需要手动设置 Goal / Metric / Verify。直接输入一个自然语言目标，编排器自动分类目标、推导 Success 谓词、与你确认一次，然后在 14 个子命令之间自主编排，直到完成。 14 个命令 | 命令 | 用途 | |------|------| | /autoresearch | 核心迭代循环，或自主编排模式 | | /autoresearch:plan | 把目标转化为验证过的配置 | | /autoresearch:debug | 假设驱动的自主 bug 猎手 | | /autoresearch:fix | 逐个击破错误直到归零 | | /autoresearch:security | STRIDE + OWASP 安全审计 | | /autoresearch:ship | 8 阶段通用发布工作流 | | /autoresearch:scenario | 12 个维度的边缘案例探索 | | /autoresearch:predict | 5 个专家角色辩论预测 | | /autoresearch:learn | 自主文档生成引擎 | | /autoresearch:reason | 对抗性辩论精炼（盲审团裁定） | | /autoresearch:probe | 8 个角色对抗性需求审问 | | /autoresearch:improve | 产品改进研究 + PRD 生成 | | /autoresearch:evals | 结果分析：趋势、平台期、收敛信号 | | /autoresearch:regression | 稳定性门禁：baseline vs candidate → STABLE/UNSTABLE | 另有 Guard 机制：在优化某个指标时设置"这个命令必须始终通过"的安全网。 安装 npx skills add uditgoenka/autoresearch 然后重启 Claude Code，14 个命令全部可用。通过 /plugin update autoresearch 升级。 v2.1 架构重写 原来的 SKILL.md 是一个 813 行的单体文件，每次调用消耗约 100K token。v2.1 把它拆成了一个 41 行的路由文件 + 12 个自包含命令文件（每个 94-120 行，每次调用约 5-8K token）。相同功能面，token 减少 95%。 9 个安全 hook 默认全部启用，可单独关闭。覆盖：阻止 node_modules 等目录进入上下文、阻止读取 .env/SSH 密钥、阻止 force-push/rm -rf、压缩后重新注入上下文、子 agent 状态感知等。 GitHub： 参考： #ClaudeCode# #Skill# #AgentLoop#

推荐这篇文章。Redis 作者 antirez 的核心论点：控制想法比控制代码更重要。 他认为审查 AI 代码已经"大部分毫无意义"——真正该做的只有两件事：掌控设计，拼命做 QA。 看看这个博客过去的历史。有很多关于用 AI 编程的文章，其中一些可以追溯到 2024 年 1 月。毕竟，我是一个还算受尊敬的开发者。我不需要作为一个寻求关注的老头子留在"圈子里"，我最近重新加入了 Redis，现在还在开发一个本地 LLM 推理的开源软件，在社区里受到了不错的欢迎。为什么我继续做这件事——说人们不想听的话？为什么我一直宣布未来的编程默认会是什么样子？因为我感到有一种紧迫感，想降低那些比我更没准备好应对变化的人受到的冲击，他们通常比我年轻，而且不像我，没有预见其中许多事情的发生（在 ChatGPT 出现之前，我就在 2022 年出版了一本书，预示了许多现在已经发生的事情，以及我相信将会发生的事情，所以我觉得我可以说这些而不显得自我中心）。 所以我的做法是一个技巧。人们越来越觉得编程被 AI 彻底改变了，不知道该怎么办，不知道自己是否真的可以用一种完全不同的方式开始编码，不再把代码当作主要的产出。他们觉得在背叛自己的领域。所以我的意图是站出来说"看着我，我会写代码，你知道的，我没有躲在 AI 后面：然而，事情变了，这不是你的弱点，不是你中了 AI 的毒。只是我们的领域正在朝着一个令人难以置信同时又痛苦（但也快乐）的方向演进。" 这就是为什么昨天我在 X 上说，我相信许多程序员现在的影响力比他们本可以达到的要小，因为他们在盯着代码看。我真的相信这一点。请注意，这并不意味着用 vibe coding 的方式直接要最终产品。重点是：如果你掌控了你软件的想法，盯着代码本身是次优的，而且常常毫无意义。 原因如下： 1. 你现在可以生成大量代码，即便不计算 LLM 的代码啰嗦问题（那也大部分是因为你还不能很好地 instruct 它们）。你打算怎么每天审查 5000 行代码？ 2. LLM 非常擅长写局部最优的代码，但在大想法上更弱（虽然在改进）。逐函数、逐行地扫描有什么意义？相反，你应该把你心里的设计 prompt 进去，有时候问"那个部分的精确设计是什么？它是怎么工作的？"然后评估它是不是正确的模型。这快得多。 3. 工作日是 8 小时。如果你在读代码，这是一个取舍。你在减少做另一件事的时间——今天你工作中最重要的那部分：问自己"我在用这个软件做什么？我想往哪个方向走？"以及想新想法、新功能、优化技巧。以及做大量的 QA。 掌控想法。记得《人月神话》里的这句话吗？一本 70 年代的书告诉我们关于当前软件时代的东西，比 2000 年到 2020 年间说的很多东西都多。为什么现在抗议 AI 的人，没有被过去十年软件的状态所震惊？我们在最近几年——在 AI 之前——触碰到的 slop 水平是不可想象的。我再告诉你一件事。什么是 slop？用 DwarfStar 我完全自动化地实现了两个 LLM（DeepSeek v4 和 GLM 5.2）的推理：但你自己试试，你会发现你不能只是说"实现 XYZ"然后就看到它能用。你必须理解事情是怎么运作的，什么是最好的设计，如何达到某个性能水平。然后我把实现和其他系统做了对比，检查正确性，发现其他实现有时包含更多错误。我进一步研究，发现本地推理领域充满了微妙的错误，累积起来会损害模型输出——attention 实现中的问题导致上下文超过某个限度后性能滑坡，因为索引 attention 的实现是坏的（比如做了超过应该做的工作），等等。这是一个非常复杂、快速变化的领域，每天都有模型发布，推理图彼此略有不同。对开发者来说，这是一个不公平的游戏。好吧：AI 在这方面的帮助极大。在许多领域，严谨的工程（在设计层面）和测试远好于手写一个 GPU kernel（或逐行读它）。所以我们确定大部分抵抗不是意识形态吗？ Matteo Collina 昨天回复我的推文问我：但你不是说过你会检查 Redis 的所有 AI 生成代码吗？这确实是一个好问题。是的，我做，但这在这一点上是我需要做的事情，但我相信大部分时候是毫无意义的——部分是在 GPT-5.5 发布之后，但现在有了 Fable 和 GPT-5.6 Sol 更是如此。是的：我发现了一些我不喜欢它们被编写的方式，但如果我打开其他 Redis 贡献者写的 Redis 文件，里面有远更糟糕的东西，不是因为他们不是好的程序员，而是因为这是一个品味问题。我写非常干净的代码，因为我希望它是可读的，所以在 Redis Arrays 的实现过程中我做了修改。我现在又在为 Redis sorted sets 的 50% 内存节省优化做同样的事，一个我很快会提交的 PR。但我不觉得这还有用了。没有人应该再盯着这段代码看，而应该只看代码包含的想法。我继续这样做是出于对用户的尊重。Redis 已经是一个被广泛使用的东西，许多程序员会打开文件，手动修改东西。但如果我完全自由，你知道我会怎么做吗？把审查占用的所有时间用来做更多的 QA，想下一个优化思路并应用它，以及用 LLM 写一个 DESIGN.md 文件——用人类语言描述每个数据结构，包含它承载的想法、实现技巧和设计。将来，这比审查代码有用得多。 你想修改 sorted sets？你打开文件，读设计文档，你就拥有了这些想法。你可以打开 agent，用正确的思维模型让它帮你做事。这比审查代码有用得多。 Fable 和 GPT-5.6 对 sorted sets 内存节省的审查，将比我自己的审查发现更多的错误和微妙的竞态条件。然而我还是会做。但对于大多数软件项目，所有这些已经不再有意义。专注于掌控想法。专注于质量、测试、以及对你想要交付的软件有一个清晰的构想。世界变了，这是痛苦的，但同时也充满了机会——去改善一个已经彻底腐烂的软件世界。 我只有一个疑问，关于那些经验不够、无法建立心智模型的年轻程序员。我们不知道他们是否需要深入理解一段代码是怎么工作的，但我相信他们应该学怎么写程序。然而，我不确定检查 LLM 输出是不是他们应该做的正确的事。学一门编程语言，实现一个小解释器、一个小数据库、一个哈希表等等——这可能有用得多。审查某个客户网站的 JavaScript？算了吧，别把时间浪费在那上面。 原文： #AIProgramming# #SoftwareEngineering# #antirez#