Posts

这里汇集由公开来源生成的 AI 情报报告，重点关注产品更新、技术变化、商业信号和 Agent 基础设施趋势。 日常早报、午间高信号与晚报保留在本分类中，不占据博客首页；战略周报与达到高价值阈值的报告会同时出现在首页。每份报告均保留可访问的信息来源，便于核验和进一步阅读。

微软发了个postgresql插件pg_durable 可以用sql编排工作流，还能保证执行完成！太厉害了，待我玩一玩

本文是阅读这篇博文后的简单记录与思考： How we built Claude Code auto mode: a safer way to skip permissions 使用Claude Code时，经常会遇到各种权限的申请，也就是human-in-the-loop，导致提了一个复杂需求给CC后，如果人离开电脑了任务就会卡在这个申请上。所以网友各种hack，使用happy或者是远程登陆软件连到自己电脑上。 CC官方新增了auto mode功能，尽可能的利用AI的能力来帮助简化审批流程。避免--dangerously-skip-permissions带来的灾难性破坏 为什么可以做 系统基于一个数据前提：CC用户通过了93%的权限申请。 这是一个很关键的前提条件，他给auto mode的实现提供了很大的可能性：仅有很小比例的情况下是需要拒绝的，如果反过来CC用户通过了7%的权限申请。，那么auto mode需要处理的情况就复杂的多了。 怎么做的 prompt注入探针 CC团队在server端实现了一个运行在服务器端的prompt注入探针，它扫描tool消息，并在发现风险时插入warning消息 为啥需要这个prompt注入探针？原因是两层决策机制没有把tool result作为输入，这可能导致prompt注入成功，这时候如果有warning消息，则agent被劫持的概率会大大降低。 两层的决策机制 在client端实现了两层的决策机制，使用Claude Sonnet 4.6 进行判断，第一层是简单输出是否拦截，当拦截时进入第二层，使用更多的reasoning token来给出更准确的判断。输入是user消息+tool消息，干掉了assistant消息和tool result 为啥是两层？因为大部分情况下不会拦截，当第一层拦截时再花费更多token去进行判断。效果是一样的，可以节省更多成本。 为啥干掉assistant消息和tool result？因为assistant消息可能会误导LLM，tool result可能会含有注入的有毒信息 结合服务端与客户端的两种自动审查，劫持主agent会变得很难 auto mode下拦截后发生了什么 不执行tool，并提示模型：find a safer path, don’t try to route around the block. 如果连续三次被拦截，或者是累积20次被拦截，则让人类来决策 如果是headless模式，则退出执行 这还挺聪明的，如果发生了拦截了不该拦截的tool调用，则多次重试可以将false positive的情况降到最低 怎么评价，结果怎样 先看效果：日常流量的误拦率从 8.5% 压到了 0.4%，但 overeager 动作还是有 17% 会漏过去。 为啥漏拦这么高？因为难点不在「看没看见危险」，而在「用户到底授没授权」。force-push、删分支模型都识别得出来，但「清理一下分支」这句话算不算允许批量删除？分类器在这条边界上经常拿不准，prompt 工程暂时也没招。 那它到底值不值得用？得看跟谁比。跟 --dangerously-skip-permissions 裸奔比，这是实打实的进步；跟逐条认真审批比，反而是退步——你把自己的判断换成了一个会偶尔出错的分类器。所以它不是给所有人的，而是接住前文那批被 approval fatigue 折磨、又不敢裸奔的用户，做 happy 这类 hack 的官方替代品。

RAG（Retrival Augumented Generation）技术对于扩充模型的知识，减少幻觉，提高实用性上非常重要。这篇文章主要是介绍一个RAG系统的各个工作环节，对应的可调节参数以及应用场景。 RAG系统的工作流程 Ingestion parsing（pdf html） chunking metadata 来源、标题、章节、日期、权限 contextual retrieval Vector db indexing dense model choice 模型维度、语言支持、是否非对称 sparse / bm25 indexing embedding/index 的更新机制 Retrieve Query processing rewrite expand HyDE query routing metadata filtering Hybrid search 融合 RRF 或加权 rerank 上下文压缩 / 去重(把检索到的内容裁剪、去冗余,省 context window) chunk 扩展(检索命中小 chunk,但喂给 LLM 时取回它的相邻上下文或父文档,即 “small-to-big” / parent-document retrieval) Generation no-answer / 兜底 prompt 拼装(把 query + 检索结果组织成 prompt) 生成 citation / attribution(标注答案出自哪个 chunk,可溯源) ...

MiroThinker 1.7 在长问题推理领域取得了SOTA的成绩，优秀的成绩是由强Model与扎实的Harness共同组成的，本文是对其Harness实现中的关键工程优化的记录。 前置背景 MiroThinker 是一个深度研究型 Agent —— 给一个复杂问题（“今天 arxiv 上 cs 的论文标题是什么”），它会自己拆任务、搜索、抓网页、跑 Python 验证，最后输出 \boxed{答案}。底子是经典 ReAct：每回合 LLM 思考 + 工具调用，结果回写历史，循环 200~300 次直到收敛。 256K 上下文 + 单任务最多 300 次工具调用，对工程是不小挑战。运行时整体长这样： flowchart TD Task["task_description (用户问题)"] --> Loop subgraph Loop ["Orchestrator 主循环 (≤200/300 turns)"] direction TB For["for turn in 1..max_turns:"] S1["① LLM 思考 → tool_call"] S2["② ToolManager → MCP Server (search / python / scrape / ...)"] S3["③ keep_tool_result：裁剪远端工具结果"] S4["④ ensure_summary_context：token 预估刹车"] S5["⑤ rollback / 中间答案池"] For --> S1 --> S2 --> S3 --> S4 --> S5 end Loop --> Condition{"结束条件"} Condition -- "成功 \boxed{}" --> Success["输出最终答案"] Condition -- "跑满 / 上下文满" --> Failure["generate_failure_summary"] Failure --> Restart["重启 attempt（≤3 次）"] 下文按"护栏机制 → 工具层 → 上下文处理"三块展开。 ...

本文是 Claude Code 源码逆向系列 的第二篇，聚焦 Skills 发现与 System Prompt 注入机制。 我最先关心的问题是：AGENTS.md 里的规则到底怎么进入模型上下文？ 恢复后，这条链路大致是： src/core/skills/agentsFile.ts：从工作目录向上查找并读取 AGENTS.md src/core/skills/prompt.ts：解析可用 skill，并构造可注入的 prompt 片段 src/core/model/request.ts：把 skills prompt 追加到 system 消息块 src/core/tools/skill.ts：提供内置 Skill 工具，支持运行时查询/加载 一个典型的 TS 片段（示意，保留结构）是这样的： 1 2 3 4 5 6 7 // src/core/model/request.ts if (params.skills && params.skills.trim()) { systemBlocks.push({ type: "text", text: params.skills, }); } 对应伪代码： 1 2 3 4 skillsPrompt = discoverSkillsFromAgentsFile(cwd) if skillsPrompt exists: append skillsPrompt into system messages send request to model 这块我有个明确取舍：先把 Skills 恢复成独立模块，不急着耦合进 runCli 主流程。原因很简单，Skills 的输入输出边界很清晰，独立后更容易做逐步校验，也更适合后续替换解析策略。 ...