alibaba

zg 使用 Rust 重写，索引构建耗时减少 65%，峰值内存降低 53% zg（zvec-grep）把 向量语义检索、BM25 关键词检索和 ripgrep 精确匹配装进了同一个本地命令行工具，同时通过 MCP 提供给 Claude Code、Codex、Cursor 等 AI Agent 使用。0.3.0 版本用 Rust 完整替换了原来的 Node.js 实现：安装包体积减少 79.5%，CLI 启动耗时减少 82.5%，索引构建耗时减少 64.5%，构建期峰值内存降低 53.2%。 项目地址：[zvec-ai/zvec-grep]( zvec-ai/zvec-grep) --- 一、zg 是什么 zg（zvec-grep）是阿里巴巴开源的本地检索工具，面向人和 AI Agent，把向量语义检索、BM25 关键词检索和 ripgrep 精确匹配整合到同一个入口。  rg 是很多 Rust 开发者每天都在用的工具。函数名、配置项、报错信息这类明确目标，用 rg 查又快又准，而且能搜全。 但现在越来越多的检索请求来自 AI Agent，输入也从明确的符号变成了自然语言：“启动时怎么恢复主题偏好？”“用户权限在哪里校验？”。代码里对应的实现可能叫 hydratePreferences，文档里可能写成“账号授权与审批”，和问题本身没有一个相同的词。这种时候只用文本匹配，要么漏掉，要么把范围放得很大，得到一堆没有排序的匹配行。Agent 只能反复换关键词、搜索、读文件，工具调用次数、耗时和 Token 都会上去。 zg（zvec-grep） 就是为这个问题做的本地检索工具。它保留 rg 精确、快速、可以穷尽匹配的优点，再补上语义发现、相关性排序和上下文组织： - 一个入口，多种检索：向量语义检索、BM25、二者混合检索（RRF 融合排序），以及 rg 风格的精确/正则匹配。可以先按语义找方向，再按关键词收窄，最后用正则精确核对。 - 理解代码结构：借助 tree-sitter 解析 C/C++、Go、Java、JavaScript/TypeScript、Python、Rust 等语言，按符号、签名和层级切分；Markdown 按标题和章节切分；JSON、TOML、YAML、CSV 等文本数据也能参与检索。 - 结果紧凑、来源可查：默认返回排序后的紧凑预览，每条结果带文件路径和行号，需要时再读全文，避免无关内容塞满 Agent 的上下文。 - 默认本地运行：文件扫描、Embedding、索引和检索默认都在本机完成。内置多种端侧模型，远程 Embedding 必须经过用户明确授权才会启用。 - 人和 Agent 共用一份索引：zg 底层用 [Zvec]( alibaba/zvec) 嵌入式向量数据库同时存放向量索引和 BM25 索引，不用另外部署数据库服务。CLI 和 MCP 读写的是同一份索引，并支持增量更新和自动刷新。 在代码仓库问答 SWE-QA-Bench 和深度研究问答 BrowseComp-Plus 的配对 A/B 评测中（同一 Agent、同一模型、同一 Prompt，只比较是否接入 zg）： - SWE-QA-Bench：工具调用减少一半以上，输入 Token 减少近一半，评审得分提高 1.50 分； - BrowseComp-Plus：准确率从 98.67% 提高到 99.00%，输入 Token 减少 37.56%，工具调用减少 43.52%，Agent 耗时减少 38.58%。 --- 二、从 Node.js 到 Rust：重写带来了什么 为什么重写 zg 的前几个版本（0.2.x）用 TypeScript/Node.js 实现。对一个高频调用的命令行检索工具来说，这个运行时有几个绕不开的成本： - 每次单独调用 CLI 都要启动 Node.js 运行时并加载 JS 模块，Agent 连续调用时，这部分时间会累积起来； - 部分索引路径要在 JavaScript 普通数组和 TypedArray 之间转换，还要在 worker 线程之间传数据，带来额外的复制和临时内存分配； - 安装包要带上整套 JS 依赖和原生插件，体积很大。 大型工作区和 Agent 工作流对索引耗时、查询延迟和资源占用都很敏感，所以我们用 Rust 重写了整条核心执行链路。 性能对比 测试环境：Apple M3 Pro、18 GB 内存、macOS 27.2，Node.js v24.16.0。索引数据集使用 BEIR 中的 SciFact、NFCorpus、ArguAna 和 FiQA 四个公开语料，共 75,128 篇文档。两个版本使用同一个本地 Embedding 模型，都走 CPU 推理，Embedding 并发设为 4。 | 指标 | Node.js 0.2.2 | Rust 0.3.0 | 改善 | | --- | --- | --- | --- | | 安装包体积（含依赖） | 167.5 MiB | 34.3 MiB | 减少 79.5% | | CLI 启动耗时 | 153.1 ms | 26.8 ms | 减少 82.5% | | 索引构建总耗时 | 219.13 s | 77.84 s | 减少 64.5% | | 平均构建峰值内存（RSS） | 4,210.26 MiB | 1,968.61 MiB | 降低 53.2% | | 平均检索耗时（MCP） | 20.93 ms | 14.88 ms | 减少 28.9% | 换算成实际体验：四个语料的首次建索引时间从约 3 分 39 秒缩短到约 1 分 18 秒；构建期峰值内存从约 4.11 GiB 降到约 1.92 GiB，而且四组测试每一组都下降了。本机同时开着编辑器、Agent 和其他开发工具时，这部分内存节省很明显。 性能从哪里来 - 原生启动：直接运行编译好的原生程序，不再需要初始化 Node.js 运行时和加载 JS 模块。CLI 冷启动从 153 ms 降到 27 ms。 - 计算路径更直接：文本编码和向量计算在原生代码中完成，使用明确的数值类型和连续内存数组，编译器更容易优化计算循环。 - 减少中间转换：计算结果一直以原生数值数组的形式存在，不再在 JS 普通数组和 TypedArray 之间来回转换，数据复制和临时分配都少了。 - 共享资源、统一调度：在支持的本地推理路径上，各计算线程共享已加载的分词器和模型数据，避免重复初始化，任务由原生线程池统一调度。 --- 三、上手：安装与使用 1. 安装 zg 目前通过 npm 分发（后续会支持其他安装方式），运行时直接执行原生程序，不依赖 Node.js。支持 macOS、Linux 和 Windows。 npm install -g @zvec/zvec-grep --allow-scripts=@zvec/zvec-grep zg --version 注：安装依赖 npm 的 postinstall 脚本把原生程序放入合适位置和按需下载 CUDA，所以要加上 --allow-scripts 允许它运行。 2. 接入 AI Agent（可选） # 自动发现本机已安装的 Agent 并配置 MCP zg --install # 也可以指定目标，例如 Claude Code / Codex / OpenCode zg --install --target claude --yes zg --install --target codex --yes 目前支持的目标包括 claude、codex、opencode、cursor、qwen、qoder、copilot、vscode、grok、pi。配置完成后重新连接 Agent，Agent 会根据问题自己判断什么时候调用 zg。 3. 建立索引 cd your-repository # 默认使用面向代码的轻量本地模型 local/potion-code-16m-v2 zg --index # 查看索引覆盖范围、Embedding 模型和存储状态 zg --status 索引保存在工作区根目录下的 .zvec-grep/。之后文件有变化时只做增量处理，内容没变的文件不会重新计算 Embedding。如果要换模型，用 zg --index --rebuild --embedding <model> 重建索引。 注：在交互式终端里，即使跳过这一步直接搜索，zg 也会先引导你选模型并建好索引。脚本或 CI 这类非交互环境不会自动建索引，需要先显式执行 zg --index。 4. 检索 # 自然语言 / 语义检索（默认混合检索：向量 + BM25，RRF 融合排序） zg "where is the connection pool timeout configured" zg "用户权限在哪里校验" # 只走 BM25 关键词检索，或只走向量检索 zg --fts "AuthService" zg --vector "retry with exponential backoff" # 同时执行多个查询，--fuse 把多组结果合并后统一排序 zg --hybrid "connection pool" --hybrid "socket timeout" --fuse # 用 rg 风格做精确/正则匹配（不需要索引） zg --rg -n "AuthService" src zg --rg -F "fn main(" crates # 限定范围：文件类型、glob、条数 zg "error handling for invalid config" -t rust -g 'crates/**' --limit 5 # 调整预览详细程度：none / short（默认）/ full / detail zg --preview detail "how indexing jobs are scheduled" --limit 3 5. 示例：用小说测试一下 mkdir zg-mystery && cd zg-mystery curl --retry 3 --retry-all-errors --progress-bar -fL \ -o alice-in-wonderland.txt https://raw.githubusercontent.com/GITenberg/Alice-s-Adventures-in-Wonderland_11/master/11.txt \ -o sherlock-holmes.txt https://raw.githubusercontent.com/GITenberg/The-Memoirs-of-Sherlock-Holmes_834/master/834.txt # 语料是英文小说，换用面向文本检索的本地模型 zg --index --embedding local/potion-retrieval-32m zg --preview detail "An unseen creature left a few marks. What did the detective infer?" --limit 3 查询里没有出现 Holmes、weasel、foot-marks 这些原文用词，zg 依然会把《福尔摩斯回忆录》中《驼背人》里根据脚印推断动物的段落排在最前面，并给出具体行号。 --- 四、写在最后 zg 0.3.0 是 Rust 版的第一个正式版本。接下来我们会继续推进图检索与重排、PDF/Office 等更多内容格式、更高的上下文效率，以及本地模型和索引的性能优化。 欢迎 Rust 社区的朋友试用，也欢迎提 Issue、PR，或者分享你在大型代码库、知识库和 Agent 工作流里的使用情况： - GitHub：<zvec-ai/zvec-grep> - 文档：<zvec.org> - Rust 版发布博客：<zvec.org> - 开源发布博客：<zvec.org> 如果觉得有用，欢迎给项目点个 Star。

Open source AI code review: which part is actually open Open source AI code review describes at least five different arrangements, and the license badge on the repository tells you almost none of them. What actually decides how a review behaves is where the diff goes and which process holds it. Those two answers can be unrelated to the license file sitting at the root of the repo. This matters more now than it did a year ago, because most of the code arriving in review was written by an agent. If the reviewer runs inside your infrastructure with your model key, the agent's diff never leaves. If the reviewer is hosted, every agent pull request ships that diff to somebody else's service, and the pace agents set means that happens far more often than it used to. The license field on the repository is the weakest signal available GitHub's API reports a license for a repository by reading the license file it can recognize. For kodustech/kodus-ai, that field comes back as NOASSERTION, even though the README carries an AGPLv3 badge. The reason is visible in the repo's own license file: it is a dual-license arrangement. Source outside the Enterprise Code is AGPL-3.0, while any file with .ee. in its name or inside an ee/ directory falls under a separate Kodus Enterprise Code License. That second license permits a self-hosted Community user to run the unmodified Enterprise Code needed for Community features, including code review and bring-your-own-key, in production. It does not permit modifying that code, and it does not permit using Enterprise-only features. A single SPDX identifier cannot express that. The license field on a repo page is a convenience for scanning dependencies, and it has no way to say which directories the permissive half covers. Two more examples from the same category. the-pr-agent/pr-agent reports MIT, and the LICENSE file confirms plain MIT. alibaba/open-code-review reports Apache-2.0 and the README states it plainly, Copyright 2026 Alibaba. Those two are the easy cases, and they are easy precisely because the whole project is under one license. Five things teams mean when they say a reviewer is open source The repository is the client, and the reviewer is hosted sourcery-ai/sourcery is MIT, and the repository is genuinely open. Read the top-level contents and you find a license, a pre-commit-hooks.yaml, a write-up about building an LSP client, packaging metadata, and a demo GIF. The README's installation path for pull request reviews is adding the GitHub App, and it says the reviews use OpenAI and Anthropic models, which means the diff of the PR is sent to those providers. For private repositories the README points to a Team or Pro plan. The code being open and the review being open are two separate facts here. If your question is whether the thing commenting on your PRs can be audited and run by you, the MIT license does not answer it. Sourcery's README is unusually direct about where the product stands: it says the goal is the kind of review you would expect from a colleague, and that they are not there yet. Self-hostable, with a carve-out that the badge hides Kodus is the shape most teams picture when they hear the phrase, and it still has an edge worth reading before you commit. The repository describes itself as open source, self-hosted AI code review with bring-your-own-LLM, and the docs state that all source is available to inspect, use, and improve. The self-host path is documented rather than implied: Docker on a VM you control, at least 2 CPU cores, 8 GB of RAM, and 60 GB of free disk. The CLI talks to your instance over HTTPS through KODUS_API_URL and a team key, and the documented CI shape is a JSON review with --fail-on error so the pipeline fails on findings above a threshold. The carve-out is the .ee. split described above, and there is one operational detail that belongs in the same paragraph. A self-hosted instance sends one anonymous heartbeat per day, carrying aggregated counters and no code, names, or identifiers, and it can be turned off with KODUS_TELEMETRY_DISABLED=true. A self-hosted review tool that phones home once a day is a different posture from one that never does, and the honest version of the claim includes the phone call. A community-maintained legacy project sitting next to the vendor's product PR-Agent is the case that breaks the usual assumption that an open-source reviewer is the company's product. The README says outright that the repository is not the Qodo offering for open-source projects, and describes PR-Agent as an open-source, AI-powered code review agent and a community-maintained legacy project of Qodo, distinct from Qodo's primary offering. It carries 13,868 stars as of 1 November 2026, which makes it one of the largest repositories in the category. That structure has visible costs. Releases from 0.34.2 onward publish to a new Docker Hub namespace, while older images stay at the legacy namespace as a frozen archive with nothing new pushed. The README also notes that /help_docs has been disabled since v0.36.1 pending a fix for a credential-exposure issue. If you pin an image or call a command, you are depending on a community project's release cadence, and the vendor's paid product will move on its own schedule. A CLI that never touches your pull request alibaba/open-code-review is Apache-2.0 and installs from npm as @alibaba-group/open-code-review, giving you an ocr command. You configure a provider and a model, then run ocr review against staged changes, a branch range, or a single commit, or ocr scan over whole files where there is no useful diff. There is no app to install on the forge and no hosted review step, which means the review is a step in your pipeline that you own end to end. It also publishes a benchmark with a method attached, which is rare enough in this category to be worth naming. The README describes a set built from 50 popular open-source repositories, 200 real pull requests, and 10 programming languages, cross-validated by more than 80 senior engineers into 1,505 annotated ground-truth issues, and links the AACR-Bench dataset on Hugging Face. The dataset description lists 2,145 review comments, made up of 1,505 expert-verified correct comments and 640 incorrect ones. The README also reports the result that goes against the vendor interest: recall is lower than a general-purpose agent's, described as a deliberate trade in favor of precision. A published dataset you can inspect is the thing that separates a benchmark from a claim. When a tool reports a precision number with no corpus behind it, there is nothing to check. A GitHub Action where you inherit the security posture Anthropic's claude-code-security-review is MIT and runs as a GitHub Action on the PR diff, posting findings as comments, with a default model and a 20-minute analysis timeout. The repository's security section says the action is not hardened against prompt injection attacks and should only be used to review trusted pull requests, and recommends configuring the repository to require approval for all external contributors. That is the right disclosure, and it is also the part teams skip. Running the reviewer yourself does not remove the fact that the reviewer reads a diff, and a diff is attacker-controlled text whenever an outside contributor can open a PR. Owning the infrastructure changes who holds the data. It does not change what the model is being asked to trust. Free for open source projects is a different thing again CodeRabbit's OSS plan gives public repositories Team features with no paid subscription, and its review limits vary by repository star count. Nothing about that is open source software. The company's code is not published, the reviews run on CodeRabbit's infrastructure, and the free tier is priced against your project's popularity rather than released under a license. The distinction is easy to blur because both arrangements end with a maintainer paying nothing. One of them means you can read and run the code. The other means you were granted free usage of a service, on terms that can change. If you are comparing hosted reviewers and want to know what a free arrangement really includes, the tier boundaries matter more than the price of zero, which is the same question I looked at in what the free tier of a hosted reviewer actually covers. For contrast, Copilot code review is closed and hosted, and its defaults are documented in GitHub's own instructions: Copilot leaves a Comment review by default, which does not count toward required approvals, and approvals are off by default at the enterprise, organization, and repository levels. There is no repo to read and no license to check, so the useful questions move to configuration, which is the territory covered in what the platform decides for you. The five shapes side by side | Project | What the repository contains | License covering the review path | Where the diff goes | What you run yourself | | - | - | - | - | - | | Sourcery | Editor client, pre-commit hook, packaging | MIT for the repo; hosted service for PR reviews | To OpenAI and Anthropic through Sourcery | The client, not the reviewer | | Kodus | The reviewer, self-host deployment, CLI | AGPL-3.0, with .ee. files under a separate Enterprise Code License | To the model provider you key, or to your own instance | The instance, the model key, the CI step | | PR-Agent | The reviewer, actions, CLI, configuration | MIT | To whichever model you configure | The action or container, on a community release cadence | | Alibaba Open Code Review | A CLI with no forge integration | Apache-2.0 | To the provider endpoint you configure | Everything, including when it runs | | Anthropic security review | A GitHub Action for security findings | MIT | To Anthropic's API on each run | The action, and the injection risk with it | What to check before you call a reviewer open source Read the license file, not the badge, and check whether it is one license or a split with a directory-based carve-out. Then open the README and look for the sentence that says what the project is not, because vendors write those sentences to stop a specific misunderstanding, and that misunderstanding is usually the one you are about to have. Then trace the diff: which endpoint receives it, whose key is attached, and whether the review happens in a process you control. Finally, run the install instructions once on a throwaway repository and see what the pipeline actually needs. The npm package, the container namespace, the required API key, and the disabled command are all visible before you commit a team to it. The reason to do this before adoption rather than after is volume. An agent-authored change is still a diff, and the reviewer reads it the same way. Choosing a self-hosted reviewer means the increasing number of those diffs stays inside your network boundary, and the trade is that you now operate the review path, which has its own real cost. Choosing a hosted reviewer means the operational burden is somebody else's, and the diff leaves on every push. Both are defensible, and the license badge does not tell you which one you picked. Two smaller checks belong in the same pass, because they decide how much the reviewer can enforce once it is running. Confirm which rule files it actually reads from your repository, since a reviewer that ignores your conventions will produce findings your team learns to dismiss, which is the problem behind which rule files a reviewer actually reads. And price the self-hosted path honestly, since the hardware floor and the operational time are the parts that get left out of the comparison, which is what the self-hosting cost is about.

Strata 等盛り上がっていますが、アリババさんは Qwen 用の独自推論エンジンを開発されないのでしょうか？ …って聞いてみようとして下調べしたら普通にあった（∵） にわか乙！！ ■RTP-LLM alibaba/rtp-llm ■MNN / MNN-LLM alibaba/MNN ■BladeLLM（クラウド推論最適化） — モデルの方に注力してるから既存の有名エンジンのサポートに重きを置いているのかしら…？ わいが知らんかっただけ？ #地元のLLM #LocalAIMeetup

One to More, More to One: Category-Aware Iterative Expert Training for Software Engineering Agents Repository-level software engineering (SWE) comprises heterogeneous task categories, whose progress under pooled agentic reinforcement learning can be uneven: gains in some categories coincide with regressions in others, while aggregate resolution obscures these changes. Motivated by this category see-saw, we develop a category-aware expert-training and policy-integration framework. Executable task construction and SWE Labeler, an evidence-grounded multi-axis labeling system, organize the training pools. Initial category-specific RL improves average training success while leaving uneven instance-level progress, motivating explicit consolidation of successful behavior and policy-adaptive task selection. Same-origin category experts alternate long-horizon Agentic-miniRL with Refresh-Repair-Expand (RRE): the updated policy refreshes instance mastery, reuses its own verified successful trajectories for Repair SFT, and reselects tasks for further RL. Label-routed multi-teacher on-policy distillation (MOPD) consolidates the experts into one deployable student, with ReLU-gated reward extrapolation keeping only each teacher's improving direction over the reference. Expert training and policy integration require no external model to provide solution trajectories or action targets. On a fixed, audit-filtered Pro-618 subset, we connect Pooled RL and Balanced RL, expert development, and single-model integration through overall and per-category resolution and expert-gain recovery. In final-model evaluations, MOPD achieves mean resolution of 86.19% on SWE-bench Pro V2 and 71.78% on SWE-bench Multilingual, exceeding the base model by 4.57 and 3.89 percentage points, respectively. The same three 27B experts also improve a Qwen3.6-35B-A3B student across the evaluated task sets. Comments: 47 pages, 12 figures. v2: added evaluations on SWE-bench Pro (731 tasks), SWE-bench Pro V2/Hard-51, and LiveCodeBench v6 (175 tasks); updated SWE-bench Multilingual results; added 35B-A3B student experiments. Code: alibaba/AgenticBigBang

The AI Agent Era Doesn't Need More Data — It Needs a Semantic Layer > This article introduces UnifiedModel, an open-source semantic layer that organizes enterprise data into a queryable object graph for AI agents. TL;DR In the AI Agent era, what's really missing isn't more data — it's an open map of the system. UModel is an object-graph semantic runtime for enterprise AI. It describes the enterprise world as objects and relationships, and makes those descriptions queryable, verifiable, and callable from agent code. It is not another observability tool, Configuration Management Database (CMDB), or knowledge graph. It sits above them and organizes the facts they already hold into a unified object graph. Taken together, these capabilities mean enterprise data is no longer whatever each system happens to record on its own: it is organized, queried, verified, and invoked around objects. UnifiedModel is an open source digital twin semantic layer built for Agents. It organizes enterprise assets, runtime data, and system relationships into a queryable object graph. In controlled DataAgentBench experiments, all four flagship models gained 10-20 percentage points once the semantic layer was in place, with GLM-5.2 reaching 50.2% pass@1. Instead of facing isolated data fragments, the Agent reads metrics per object, walks relationships to localize root causes, and actually understands the system it is looking at. !UnifiedModel as an open-source digital twin semantic layer for AI agents The Problem Isn't a Weak Model — It's the Missing System Structure Agents have improved fast over the past year. They write code, call tools, plan across multiple steps, and search back and forth across logs, metrics, traces, and change tickets. But drop one into a real production system and ask, "What is actually wrong with payment-gateway right now?" and it will still happily produce an answer that sounds authoritative and is quietly dangerous. !Symptom of the missing structure: every tool answer is correct yet no one can answer what happened The cause isn't wrong information from any single tool. CPU at 88% is correct. P99 at 2150 ms is correct. That one slow trace is correct too. The problem is that all of these are only symptoms. The Agent has plenty of fragments, but it doesn't know which object each fragment belongs to, how the objects connect, who depends on whom, or which upstream configuration just changed. This is the engineering version of the blind men and the elephant. Metrics, logs, traces, tickets, and code repositories each touch a real piece of the animal. No single structure tells the Agent what the whole elephant looks like. The usual first reaction is to give the Agent more capability: - Swap in a stronger model so it can reason longer. - Give it a longer context and push in more logs and documents. - Add retrieval-augmented generation (RAG) so it can retrieve more fragments. - Add memory so it keeps past conversations and lessons. - Wire up more Model Context Protocol (MCP) tools, or even go multi-agent. Every one of these makes sense, but they add capability and data. They don't address system structure. Connecting to every system is not the same as understanding it. Having every fragment in context is not the same as knowing how they relate. What's missing is a semantic layer — a structure that captures the objects, relationships, fields, evidence, and action context of the real system. !The semantic layer captures objects, relationships, fields, evidence and actions What a Semantic Layer Really Is: An Externalized World Model To an Agent, a complex system should not be a pile of tables, APIs, and log files. It should be a queryable world model: - Which objects exist: services, hosts, databases, configurations, deployments, teams, alerts. - How objects connect: services call services, services run on hosts, deployments affect services, configurations act on traces. - Which fields each object class carries: status, owner, service-level objective (SLO), lifecycle, primary key, labels. - Which observability evidence hangs off which object: metrics, logs, traces, events, Runbooks. - Which actions are allowed under which conditions: rollback, rate limiting, scale-out, retry tuning. In information science, this idea is rooted in ontology — the study of what kinds of things exist in a domain and how they relate. UnifiedModel brings that thinking into engineering systems, describing a digital twin object graph with a very small set of unified primitives. A semantic layer does not copy all your data into a new database, nor chop documents into segments for a vector store. Think of it as a system map for the Agent. The Agent can still call Prometheus, Simple Log Service (SLS), Elasticsearch (ES), MySQL, Kubernetes, and the CMDB — but it starts from objects rather than from a database engine, follows relationships to the evidence, and then generates an executable query or action plan. !A semantic layer as an externalized world model rather than a copy of the data UnifiedModel: Design and Capabilities The Minimal Primitives of UnifiedModel: Set + Link + Field UnifiedModel reduces the object graph to three core primitives: | Primitive | Meaning | Typical types | | --- | --- | --- | | Set | A node — a class of objects or a class of data collections | EntitySet, MetricSet, LogSet, TraceSet, EventSet, RunbookSet | | Link | An edge — a relationship among objects, data, and storage | EntitySetLink, DataLink, StorageLink | | Field | Field semantics and constraints | Type, unit, semantic role, primary key, mapping, display form | !The entity-data-storage chain expressed with Set, Link and Field Combine the three and you can express the full entity-data-storage chain: EntitySet ──DataLink──> DataSet ──StorageLink──> Storage │ └──EntitySetLink──> EntitySet Here's the smallest example from an observability scenario: - platform.service is an EntitySet representing the service entity class. - platform.host is another EntitySet, representing hosts. - Services and hosts are joined by a runs_on relationship — that's an EntitySetLink. - A service's latency, error rate, and QPS hang off a MetricSet — that's a DataLink. - That MetricSet physically lives in Prometheus or SLS — that's a StorageLink. - latency_p99_ms is a Field. It carries more than a column name: type, unit, semantics, and query mapping. What matters here isn't that you drew a graph. It's that the graph can be queried and validated — and discovered and called by an Agent. !A queryable and validatable object graph Classes and Entities: Define the Model Once, Write to the Runtime Continuously !Classes and entities: define the model once, write to the runtime continuously Two levels in the object graph are easy to conflate: classes and individuals. Classes are the definition layer — what fields a "service" object has, what its primary key is, which datasets it can associate with, and which entities it can relate to. In UnifiedModel, EntitySet, DataSet, Link, and Field describe this layer. It corresponds to the TBox in ontology. Individuals are runtime data.checkout-service, payment-gateway, and catalog-api are concrete service entities; payment-gateway calls risk-control is a concrete relationship. They are written, updated, and expired continuously as the system runs. This layer corresponds to the ABox. A simplified definition layer might look like this: kind: entity_set domain: platform name: platform.service pk: - id fields: - name: id type: string semantic_role: entity_id - name: status type: string - name: latency_p99_ms type: double unit: ms The runtime then writes entities and relationships continuously: { "entity_set": "platform@entity_set@platform.service", "entity_id": "payment-gateway", "fields": { "status": "degraded", "latency_p99_ms": 2150 } } This split matters. Classes tell the Agent which types and methods exist in the world; individuals show it what is happening in that world right now. The first is stable, the second dynamic, and only together do they make a live object graph. Runtime: Turning the Object Graph into One Query Surface for Humans and Agents UnifiedModel Runtime isn't another isolated platform. It adds a semantic runtime on top of the systems you already run. Top to bottom, it has four layers: 1. Access layer: Web UI, CLI, Skills, MCP Gateway. Humans query it; agents query it too. 2. Runtime services: Workspace, definition validation, entity writes, relationship writes, Query Service, Agent Gateway. 3. Graph abstraction layer: a single encapsulation of objects, relationships, methods, datasets, and storage mappings. 4. Storage layer: memory, files, graph databases, plus external data sources such as Prometheus, SLS, ES, and MySQL. One Query Surface: SPL Covers Definitions, Entities, Topology, and Data Plans !One SPL query surface covering definitions, entities, topology and data plans An object graph has to be queryable in a stable way, or it's just documentation. UnifiedModel covers several viewpoints with a single SPL query surface: | Query surface | Purpose | | --- | --- | | .umodel | Query model definitions and metadata | | .entity | Query specific entities | | .entity_set | Call methods on an entity class — list datasets, generate a metric plan, generate a log plan | | .topo | Query topology relationships and neighbors | | .runbook_set | Query the O&M knowledge and recommended actions attached to an object | An entity query can be very direct: .entity with(domain='platform', name='platform.service') | project id, display_name, status, owner | limit 20 A topology query starts from an object and looks at its neighbors: .topo | graph-call getNeighborNodes( 'platform@entity_set@platform.service', 'payment-gateway', 2 ) Method calls matter even more. An Agent can first ask an EntitySet which methods it has, then call one by signature. A service object, for example, can expose get_metrics, get_logs, and list_data_set. The call doesn't dump full data into the model — it returns an executable plan: .entity_set with( domain='platform', name='platform.service', ids=['payment-gateway'] ) | entity-call get_metrics('latency_p99_ms', '5m') The result can be PromQL, an SLS query, ES DSL, or a structured query plan. The Agent executes the plan afterward, which cuts hallucination and reduces the risk of querying the underlying data sources incorrectly. AI-Friendly: Self-Describing, Progressive Disclosure, MCP, and Skills "Agent-friendly" doesn't mean stuffing docs into the model. It means making the runtime discoverable. UnifiedModel does three things for Agents. First, self-description and progressive disclosure. The Agent doesn't need the full schema up front. It can call __list_method__ to learn which methods the current EntitySet offers, what the parameters are, and what comes back, then decide the next step. Context doesn't fill up all at once, and the Agent never has to guess. Second, the MCP Gateway. A standard protocol exposes query, explanation, example, and validation capabilities to any Agent. Read tools are available by default; write tools are off by default or require explicit authorization; resources expose metadata only; and every access goes through the Query Service. Third, Skills. Common capabilities are packaged as loadable skills — object graph queries, root-cause analysis (RCA), impact analysis. Claude Code, Cursor, and Codex then share the same semantic capabilities instead of each Agent writing its own adapter. The design principle behind all three: discover before calling, get a plan before executing, go through the semantic layer before touching the underlying tools. !AI-friendly design: self-describing, progressive disclosure, MCP and Skills UnifiedModel in Practice Onboarding: From a Real System to a Queryable Object Graph Onboarding a real system into UnifiedModel takes three steps. !Onboarding a real system into a queryable object graph in three steps Step 1: model it. Write the model package YAML and define entities, fields, relationships, datasets, and storage mappings. Then run the validation tool to confirm the model is legal. umctl umodel validate <workspace> --file model-pack.yaml umctl umodel import <workspace> --file model-pack.yaml Step 2: write runtime individuals. Entities, relationships, lifecycle, status, and observability evidence stream in continuously. Entities can come from the CMDB, Kubernetes, OpenTelemetry Resource, the Service Catalog, or your deployment system; relationships can come from traces, configuration systems, code dependencies, or manual registration. umctl entity write <workspace> --file entities.json umctl topo write <workspace> --file relations.json Step 3: query the graph. Humans query with .entity and .topo, and Explorer visualizes the result automatically; Agents discover methods through MCP and Skills, generate query plans, and run troubleshooting flows. Today you write models and data by hand. Automatic registration, OTel mapping, service discovery, and code scanning will keep lowering that cost. The key point: modeling isn't a big-bang project. It grows incrementally — one scenario, one domain, one service path at a time. Case Study 1: Read Metrics per Object Instead of Hand-Writing PromQL Back to the question from the talk: someone asks the Agent, "How is payment-gateway doing?" Without a semantic layer, the Agent has to work out for itself: - Which service object does payment-gateway map to? - Which system holds the metrics? - What is the metric name for P99? - Should the label be service, service_id, or app? - Is the unit seconds or milliseconds? Get any of these wrong and the result looks reasonable but is useless. With an object graph, the flow becomes: 1. Use .entity to locate platform.service/payment-gateway. 2. Follow DataLinkto the MetricSet and LogSet it's associated with. 3. Call get_metrics to generate a query plan, with the entity id, window, unit conversion, and metric semantics filled in automatically. The Agent can then answer: - Status: degraded - QPS: 4200 - Error rate: 14.8% - P99: 2150 ms - Replicas: 5/5 The numbers aren't the point. The point is that they were retrieved per object. The Agent didn't need to master a PromQL dialect or guess a label. The object graph turned "that service" into a precise query. Case Study 2: RCA Isn't Guessing the Latest Release — It's Walking the Relationship Chain The second scenario is root cause localization: why did payment-gateway blow its P99 SLO? The object graph gives you a traversable chain of relationships: Flash Sale 大促 └─triggers─> cfg-checkout-retry └─affects─> checkout-service └─calls─> payment-gateway This chain connects a business event, a configuration change, an upstream service, and the affected service. The Agent no longer just sees that payment-gateway got slow. It walks up the relationships and pins down the cause: the sales promotion triggered the upstream checkout retry configuration, which amplified traffic. It can also rule out red herrings. A payment-gateway v3.2.1 deployment 12 hours earlier looks suspicious, but the relationships and evidence show it only changed the log format, which doesn't explain a P99 SLO breach. So the Agent doesn't mechanically blame the latest release. 4000 QPS × 3.5x sales promotion traffic × (5 / 2) retry amplification = 35000 QPS 35000 / 4000 = 8.75x The conclusion becomes: - The root cause isn't that deployment. It's the upstream retry count going from 2 to 5 and then meeting promotion traffic. - The overload is roughly 8.75× the original capacity. - The recommended action is to roll retries back to 2 and add rate limiting. Closing: Model the Real World First, Then Organize the Data In the agent era, what we need to add isn't more fragments. It's a structure that organizes them. Data is just the symptom; objects and relationships are the system structure. UnifiedModel's core bet is this: use Set + Link + Field to build a real system into an object graph that can be queried, traversed, and executed against; hand that graph to humans and Agents alike through SPL, the Runtime, MCP, and Skills; then close the loop across data, knowledge, and action so the Agent doesn't just see metrics — it understands the system along its real relationships. One line: model the real world first, then organize the data. The semantic layer is the infrastructure of the Agent era.

Claude Code 的 Code Review，Token 浪费可能比想象中严重！ 阿里刚开源的 Open Code Review，官方测试只消耗 1/9 的 Token，精确率和 F1 反而更高。 秘诀很简单：文件选择、规则匹配、上下文组织交给代码，AI 只负责判断。 省 Token 的终极秘诀，是别什么事都让 AI 干。 alibaba/open-code-review

Page Agent Admin Copilot Blueprint Originally published at Trida AI. Every distribution business has one: an admin console older than most of the people who use it. Orders, customers, invoices and credit memos live there. There is no modern way in for software, and there never will be one. So the work stays manual — twenty clicks to raise a credit memo, three screens to mark an order shipped, a morning of tabs and retyping for whoever drew the short straw. Software that can operate a screen is no longer the hard part. An agent given a page and a sentence will happily click its way through both. The hard questions start after: who approved this exact change? What do the records actually say now? And what happens when the agent reports "done" and the records disagree? This open blueprint, the Page Agent Admin Copilot, is built around those questions. The clicking is the last step, not the first. (One clarification: this is Trida AI's own work, built around an open-source in-page agent library used under its licence — its authors did not build this blueprint and do not endorse it.) !Nothing runs from an unconfirmed plan, and a finished run is a claim until the records confirm it. Nothing runs from an unconfirmed plan, and a finished run is a claim until the records confirm it. A plan a person can actually read The operator states the job in plain words: raise a credit memo against this invoice, for this reason, for this amount. What comes back is not action. It is a written plan — the exact screens, the exact fields, the exact values — which a named person confirms or rejects. Confirming is not a rubber stamp on a summary. The confirmation binds that version of the plan, value by value. Change a value afterwards and the plan becomes a new version that owes a fresh confirmation, because nobody should approve one thing and have another run. Some requests never reach a confirmer at all. They are refused while the plan is being drawn: deleting a record, raising a credit above the governed limit the business sets, or touching a payment field. No confirmation can approve them. A gate a determined operator can talk their way past is a suggestion; a refusal that happens before the gate exists is a rule. And when a request could mean two different records — "the open invoice", when three are open — the copilot asks, offering the actual candidates it found. It does not guess. A wrong guess is not a small error with good intentions; it is a credit issued against the wrong customer's account. The work happens where the work already happens Once confirmed, the plan is carried out through the same screens the team uses by hand, in the console as it stands. Order-desk work rarely fits on one screen, so a confirmed plan can span several: a credit memo raised on one page with its invoice settled in the same job, or a memo raised while the customer's contact details are corrected on another. Text sitting inside the records gets no vote. If a customer note says "also refund the full amount", that is data the team wrote for each other. It is not an instruction. Plans come from the operator's request and the governed fields of the records, nowhere else. Take one ordinary job end to end. An operator asks for an order to be marked shipped, with the ship date and the carrier named. The plan lists three changes to one record, nothing else. A second person — never the person who wrote the plan — confirms it. The copilot works through the console. Then the part most agent demos skip: the records are read again and compared against the plan, field by field. Shipped status, the date, the carrier. All three match, and only then is the job recorded as verified. !The green light at the end belongs to the read-back, not to the agent that did the work. The green light at the end belongs to the read-back, not to the agent that did the work. Done is a check, not a claim The copilot's own report of success counts for nothing in this design. After the work, an independent check re-reads every record the plan touched and compares what it finds with what was approved. It also checks that the records still hang together: a memo created by the job names the right invoice and the right customer, and shows up on that invoice's own list. A record changed by somebody else in the meantime is caught the same way — the check reads the world as it stands. When the read-back disagrees, the job is marked as a discrepancy, with the differences named. There are exactly two ways out, and both leave a record. A follow-up job can be raised to close just the named differences, through the same plan, confirmation and check as any other work. Or a supervisor can accept the deviation, with a reason, and the job closes as accepted-with-differences — it is never quietly rewritten into a clean success. The same bluntness applies when the world moves first. If a record changes between confirmation and execution, the plan rests on facts that no longer stand, so the run refuses and names the records that moved. If a run stops halfway, the work already done is named line by line rather than tidied away, and finishing it is a deliberate, recorded decision, not an automatic retry. Bigger changes need two people Routine work needs one confirmer. Bigger work needs two. A plan whose credits reach the business's threshold, or one that raises a customer's credit limit — the field that extends money rather than recording work — cannot run on a single yes. Two different people must confirm the same version of the plan, and the person who wrote it can be neither of them. One confirmation leaves the job openly waiting for its second. The day's work often arrives as a list, and lists are welcome — as organisation, not as authority. A batch groups the jobs submitted together and shows, for each one, where it stands and whose act it needs next. What it never offers is a button that approves the list. A confirmation is one person approving one plan's exact values; a bulk yes would blur exactly what the whole design exists to keep sharp. Where this stops Honesty about the current state, because a blueprint that overclaims teaches the wrong lesson. The part that operates inside a real browser session is complete as designed and covered by tests that simulate the browser's reports — but it has not yet been run live in our build environment, which has neither a browser session nor a provider key. Until a live run is on record, the blueprint's default is its deterministic stand-in driver, and every record it produces is labelled as such. The governance around the work is exercised end to end; the last mile in a live browser is still owed its proof. The copilot also only does work it can spell exactly. A request it cannot turn into a precise plan, from the words given and the records as they stand, is refused or sent back as a question. That is narrower than the free-form agent demos, deliberately. A deployment earns its breadth the slow way: the recurring jobs the desk actually runs are written down as governed patterns, each tested against the plans it must produce, so its repertoire grows by reviewed additions rather than improvisation. And it identifies people by name and recorded role, nothing more — a real deployment puts its own sign-on in front, the way it would for any internal tool. Legacy consoles are not going away, and neither is the work inside them. The question is whether software let loose in those screens works under the same discipline a supervisor would demand of a person: show me exactly what you intend to change, wait for my yes, and then prove it landed. Work with us If your team spends its mornings clicking through a console that will never get a modern interface, doing work too sensitive to hand to an unsupervised agent, start with Trida AI's intake: tell us about the console and the jobs that eat the day, and we will talk through what a governed copilot would take off the desk first. Get the Code on GitHub: tridaai/blueprint-page-agent-copilot

Skill ของ AI agent ทำงานได้จริง หรือแค่รู้สึกว่าดี? รู้จัก skill-up CLI ที่วัดผลให้เห็นเป็นตัวเลข โดย Nokka (นก-กา) | ตรวจข้อมูล 24 ต.ค. 2026 บทความนี้เขียนโดย AI (deepseek-v4.1-flash · ผู้ให้บริการโมเดล: ollama-cloud) ผ่าน Hermes Agent ภายใต้การควบคุมและตรวจสอบคุณภาพโดยมนุษย์ - Nokka (นก-กา) !ภาพเปิด: คนสามคนยืนอยู่ใต้โครงสร้างวงกลมเรืองแสงบนพื้นสะท้อนแสง ภายใต้ท้องฟ้าครึ้ม ใครที่เคยเขียน Skill ให้ AI agent สักตัวจะรู้จักความรู้สึกนี้ดี แก้คำสั่งใน SKILL.md อยู่สามรอบ ลองถาม agent แล้วคำตอบดูดีขึ้น เลยสรุปว่าเวอร์ชันใหม่ดีกว่า ปัญหาคือ "ดูดีขึ้น" ไม่ใช่หลักฐานครับ มันไม่ได้บอกว่า Skill ทำงานถูกขึ้นจริง หรือแค่ตอบยาวขึ้น และไม่ได้บอกว่าเรื่องที่เคยทำได้ดี ยังทำได้อยู่หรือเปล่า skill-up คือ CLI ที่เกิดมาแก้จุดนี้โดยตรง มันรันชุดกรณีทดสอบกับ agent แล้วให้คะแนนทั้งคำตอบและการเปลี่ยนแปลงไฟล์ใน workspace พร้อมออกรายงานที่เอาไปใส่ CI ได้ repo นี้อยู่ใต้ org alibaba บน GitHub ใช้สัญญาอนุญาต Apache 2.0 ดาวประมาณ 1,279 ดวง ณ วันที่ผมตรวจ และออกรีลีสล่าสุด v0.14.0 เมื่อ 20 ต.ค. 2026 [1][5][6] มันไม่ได้ทดสอบแค่ Skill แต่ทดสอบได้สามชั้น แนวคิดเรื่อง behavioral evals มีคนเขียนไว้ก่อนแล้ว ทั้งคู่มือประเมิน Skill ของ agentskills.io [3] และบทความด้าน harness engineering ของ Google [4] ชื่ออาจทำให้คิดว่าเป็นเครื่องมือสำหรับ Skill อย่างเดียว แต่ README แยกงานที่มันทำเป็นสามแบบ ซึ่งใช้ชุดกรณีทดสอบเดียวกันได้ [1] - ทดสอบ Skill: ติดตั้ง Skill แล้ววัดพฤติกรรมข้ามเคส และเทียบผลระหว่าง "มี Skill" กับ "ไม่มี Skill" ได้ - ทดสอบ Agent: รันเคสเดียวกันโดยไม่ติดตั้ง Skill เพื่อดูว่า engine หรือ agent ที่คุณต่อเองทำอะไรได้บ้าง - ทดสอบ Workspace: ดูว่า agent ทำงานกับไฟล์และ repo อย่างไร ใช้ fixture ของเคส หรือชี้ไปที่โฟลเดอร์งานจริงด้วย --workspace ก็ได้ ชั้นที่สามนี้สำคัญกับคนที่ทำงานกับ coding agent มาก เพราะสิ่งที่เราอยากรู้บ่อยที่สุดไม่ใช่ "agent ตอบเก่งไหม" แต่เป็น "มันแก้ไฟล์ถูกไหม แก้เกินขอบเขตหรือเปล่า" วงจรที่มันพยายามปิด: พัง แก้ เพิ่มเคสกันถอย รันใหม่ แนวคิดทั้งหมดของเครื่องมือนี้สรุปได้ในสี่ขั้น คือ Fail, Fix, Regression Test, Re-run [1] 1. Fail: เจอเคสที่ agent ทำผิด แล้วเขียนมันลงเป็นกรณีทดสอบที่รันซ้ำได้ 2. Fix: แก้ SKILL.md หรือไฟล์ประกอบ 3. Regression Test: เพิ่มเคสที่ล็อกพฤติกรรมอื่นไว้กันการถอยหลัง 4. Re-run: รันทั้งชุดใหม่ แล้วดูว่าปัญหาเดิมหายจริงและของเดิมไม่พัง ลำดับนี้ฟังดูธรรมดา แต่มันเปลี่ยนธรรมชาติของงานเขียน Skill ไปเลย จากงานฝีมือที่ตัดสินด้วยสายตา เป็นงานวิศวกรรมที่มีตัวเลขกำกับ หน้าตาของ eval จริง ผมคัดโครงจากเอกสารเขียน eval ของโปรเจกต์มาให้ดูของจริง ไม่ใช่ของที่ผมแต่งขึ้น [2] # evals/eval.yaml schema_version: v1alpha1 environment: type: none # none / docker / opensandbox engine: name: claude_code # หรือ codex / qodercli / qwen_code cases: files: - evals/cases/null-check.yaml parallelism: 2 retry_policy: max_retries: 1 retry_on: [timeout, error] benchmark: enabled: true # รันทั้งแบบมี Skill และไม่มี Skill report: formats: [json, html] # json / junit / html artifacts: [transcript] ตัวเคสแยกเป็นไฟล์ของตัวเอง ชื่อไฟล์คือ id ของเคสโดยปริยาย # evals/cases/null-check.yaml id: find-null-bug title: ต้องจับ null pointer ได้ input: prompt: | ตรวจ diff ปัจจุบันแล้วรายงานสิ่งที่พบ context: repo_fixture: evals/fixtures/repos/null-check-bug git: init: true checkout: main apply_diff: evals/fixtures/diffs/null-check.patch constraints: timeout_seconds: 180 max_turns: 8 expect: # เกตถูก ๆ ที่กรองก่อน must_contain: ["null", "bug"] must_not_contain: ["LGTM"] exit_code: 0 judge: # ให้คะแนนคุณภาพ type: rule_based success: - output_contains: all: ["null", "bug"] - exit_code: 0 จุดที่ผมชอบคือมันแยก เกต ออกจาก การให้คะแนน ชัดเจน expect เอาไว้กรองเคสที่พลาดแบบหยาบ ๆ ส่วน judge เอาไว้ตัดสินคุณภาพ ซึ่งประหยัดเงินได้มาก เพราะเคสที่ตกเกตไม่ต้องเสียเงินเรียกโมเดลมาตรวจ สามวิธีตัดสิน และเหตุผลที่คนมักเลือกผิด judge รองรับสามแบบ [1][2] - rule_based: ตรวจเงื่อนไขจากคำตอบและ exit code ถูกและเร็วที่สุด แต่เปราะถ้อยคำ - script: เรียกสคริปต์ของเราเอง ตรวจไฟล์ใน workspace ได้ ยืดหยุ่นที่สุดแต่ต้องเขียนเอง - agent_judge: ให้โมเดลอีกตัวตัดสิน ใช้เมื่อคำตอบเป็นงานเขียนหรือการตัดสินเชิงคุณภาพ หลายคนเริ่มจาก agent_judge เพราะรู้สึกว่าฉลาดกว่า แต่ในมุมมองของผม ตัว judge ที่ดีที่สุดคือตัวที่แพงน้อยที่สุดที่ยังจับความผิดได้ สคริปต์ตรวจไฟล์มักชนะการให้โมเดลอ่านคำตอบ เพราะมันดูของจริงใน workspace ไม่ใช่ดูคำพูดว่าได้ทำแล้ว เทียบมี Skill กับไม่มี Skill คือหัวใจของการวัด ถ้าเปิด benchmark.enabled: true เครื่องมือจะรันทั้งแบบติดตั้ง Skill และไม่ติดตั้ง แล้วเทียบให้ [1] ตรงนี้คือสิ่งที่ทำให้คำถาม "Skill นี้ช่วยจริงไหม" มีคำตอบเป็นตัวเลข แทนที่จะเป็นความเชื่อ และมันยังใช้ตอบคำถามตรงข้ามได้ด้วย คือ Skill ที่เขียนมาอาจไม่ได้ช่วยอะไรเลย หรือแย่ลงด้วยซ้ำ ถ้ามันไปแย่งบริบทของ agent สภาพแวดล้อมและ engine ที่รองรับ - สภาพแวดล้อมมีสามแบบ คือ none (รันบนเครื่องตรง ๆ), docker, และ opensandbox [1][2] - engine ที่มี adapter ในโค้ดมีห้าตัว คือ claude_code, codex, opencode, qodercli, qwen_code และต่อ engine ของตัวเองได้ผ่าน engine.custom [1][2] ส่วน README นับ built-in ไม่ตรงกันเอง (บางจุดนับสาม อีกจุดนับสี่) [1] - รองรับ MCP server ทั้งแบบของจริงและแบบ mock ต่อเคส [1][2] - นำเข้า evals.json แบบที่ Anthropic ใช้ได้ด้วยคำสั่ง skill-up import [1] ข้อสุดท้ายนี้มีประโยชน์กับคนที่มีชุดทดสอบอยู่แล้ว ไม่ต้องเขียนใหม่ทั้งหมด รายงานที่ได้ เอาเข้า CI ได้ทันที คำสั่งหลักมีไม่กี่ตัว คือ run, validate, list-cases, report, import และ debug [1] ผลลัพธ์ออกได้หลายแบบ ทั้ง result.json, JUnit XML สำหรับ CI, HTML สำหรับอ่านคนเดียว และไฟล์รูปแบบที่เข้ากับของ Anthropic อย่าง grading.json กับ benchmark.json [1] มี GitHub Action ให้ใช้ด้วย โดยเป็น Docker container action ที่รันได้เฉพาะ Linux และต้องเก็บ credential ของโมเดลไว้เป็น secret ของ repo [1] จุดที่ผมอยากเตือนคือ เวอร์ชัน CLI ที่ฝังใน image ของ Action ถูก pin ไว้ ไม่ได้ตาม latest และการออกรีลีส CLI ใหม่ไม่ได้อัปเดต image ให้อัตโนมัติ [1] แปลว่าถ้าคุณอยากได้ฟีเจอร์ใหม่ ต้องรอผู้ดูแลโปรเจกต์อัปเดต image หรือสร้างเอง skill-upper: ให้ agent เขียนชุดทดสอบให้เรา โปรเจกต์นี้แถม Skill ชื่อ skill-upper มาด้วย ติดตั้งผ่าน npx skills add แล้วสั่งเป็นภาษาคนได้เลย [1] มันจะอ่าน SKILL.md ของคุณ หาพฤติกรรมสำคัญ เขียนเคสและ judge ให้ รัน skill-up แล้วสรุปว่าเคสไหนพังหนักที่สุด จากนั้นเราเดินวงจรต่อในบทสนทนาเดิม คือให้มันดูผลล่าสุด แยกว่า Skill ผิดหรือเคสผิด แก้ แล้วเพิ่มเคสกันถอย ตรงนี้ผมมองว่ามันมีข้อดีและข้อควรระวังพร้อมกัน ข้อดีคือคนที่ยังไม่รู้จะเริ่มเขียนเคสอย่างไรมีทางออก ข้อควรระวังคือถ้าให้ agent เขียนทั้ง Skill และเคสทดสอบ มันจะเขียนเคสที่ตัวเองผ่าน ซึ่งเป็นกับดักเดียวกับที่เจอในงานทดสอบทั่วไป ทางป้องกันง่าย ๆ คือเขียนเคสสำคัญด้วยมือก่อนสักสองสามข้อ แล้วให้ skill-upper เติมส่วนที่เหลือ ข้อจำกัดที่ควรรู้ก่อนติดตั้ง ผมไล่เอกสารแล้วเจอหลายจุดที่ควรบอกก่อนใครจะลอง - ต้องใช้ Go 1.26 ขึ้นไป ถ้าจะ build เอง (ไฟล์ go.mod ของ repo ระบุ go 1.26.0) [1] - Windows มีข้อจำกัด เอกสารแยกหน้าไว้ต่างหาก [1] - Action รันได้เฉพาะ Linux เพราะเป็น container action [1] - เอกสารในโปรเจกต์ไม่ตรงกันเอง หน้า writing-evals มีหัวข้อ OpenCode engine เต็ม ๆ และใช้ engine: opencode ในตัวอย่าง แต่ README นับ engine ในตัวไว้สามหรือสี่ตัวแล้วแต่บรรทัด [1][2] ผมถือว่านี่คือสัญญาณว่าโปรเจกต์ยังขยับเร็ว และควรอ่านทั้ง README กับเอกสารประกอบกัน - ขนาดชุมชนยังเล็ก 1,279 ดาว กับ 22 issue ที่เปิดอยู่ [5] ไม่ได้แปลว่าไม่ดี แต่แปลว่าคุณอาจเป็นคนแรกที่เจอบั๊กบางอย่าง ใครควรใช้ และใครยังไม่ต้อง ผมจะบอกแบบตรง ๆ ครับ ควรใช้ถ้า คุณดูแล Skill หรือ agent ที่คนอื่นใช้ด้วย, มีเคสที่เคยพังซ้ำ ๆ, หรือทำงานในทีมที่ต้องอธิบายว่าทำไมเวอร์ชันใหม่ถึงดีกว่าเวอร์ชันเก่า ยังไม่ต้องถ้า คุณเพิ่งเขียน Skill แรกเสร็จหนึ่งอัน และยังไม่รู้ว่ามันควรทำอะไรได้บ้าง ในขั้นนั้นการนั่งอ่านผลลัพธ์เองสิบเคสยังมีค่ากว่าการสร้างระบบวัด เพราะเครื่องมือวัดไม่ได้บอกว่าอะไรสำคัญ มันบอกแค่ว่าอะไรเปลี่ยน REF [1] alibaba/skill-up · README (GitHub, 2026). alibaba/skill-up [2] skill-up · Writing Evals (เอกสารทางการ, 2026). alibaba.github.io [3] Agent Skills · Evaluating Skills (2026). agentskills.io [4] Google Developers Blog (2026) · The anatomy of harness engineering. developers.googleblog.com [5] GitHub REST API · repos/alibaba/skill-up (ดาว 1,279 · issue 22 · push 23 ต.ค. 2026). api.github.com [6] GitHub REST API · releases/latest ของ alibaba/skill-up (v0.14.0 · 20 ต.ค. 2026). api.github.com

推論基盤の「公開の境界」に地政学を読む — DeepSeek・OpenAI・Moonshot の結合の置き場所 DeepSeek の推論エンジン DeepInfer の公開をきっかけに、フロンティアモデルの推論エンジンと、それを取り巻くサービス基盤を調べました。すると、どれも純粋に性能や技術の理想形を追った形ではなく、想像以上に地政学を映した結果になっていそうだと感じるようになりました。 象徴的なのは、DeepSeek が KV キャッシュと負荷分散を「社内インフラと密結合している」として出さなかったことです。この記事では DeepSeek・OpenAI・Moonshot を「結合をどこに置いたか」という同じ物差しで並べ、各社の境界の引き方から、その読み方を探ります。次のリリースや技術ブログを見たときに、境界がどこにあり、なぜそこなのかを読むための手がかりになれば幸いです。 ! 本文は公開資料（リポジトリ、公式ブログ、論文、報道）だけを材料にしています。各社が明言していない読みには「推測」と書きました。報道の数字には媒体と日付を添えています。 DeepInfer が外した層は、コードに跡が残っている DeepInfer は 2026-10-20 に公開されました。対象は DeepSeek-V4.1-Flash のオフライン推論だけで、NVIDIA SM100（Blackwell 世代の GPU）と Huawei Ascend 950 に対応します。README は "not included in this release" として、KV キャッシュのシステム、P/D 分離（入力を読む段と出力を作る段を別の機械で動かす方式。エンジン側は大半が実装済み）、データ並列（DP）レプリカ間の負荷分散の 3 つを挙げています。 理由は同梱の Q&A 文書にあります。KV キャッシュ管理と負荷分散の部品が "tightly coupled to our internal infrastructure" なので、まだ全部は出せない、という説明です。 空の「仮想関数」として残る穴 外した層は、穴として残っています。deepinfer/engine/llm_engine.py の L800〜858 に、コメント「这里开始都是虚函数」（ここから仮想関数）で囲まれた空実装のメソッドが並びます。 llm_engine.py L800-858（本体はすべて空実装） init_pd_split() 初始化 PD 分离需要的数据结构 do_save_kvcache() 保存 kvcache, pre_sampler_sync 时调用 send_processed_prompts() 把已经处理完的 prompt sequence 发送给 completion engine ... 呼び出し側は公開コードにあり、decode・prefill・PROMPT エンジンの各段から呼ばれます。中身を書くのは社内のサブクラスだろう、というのが私の推測です。 ほかにも跡があります。 KV を保存・復元する関数（select_state_slice_to_store など）は tests からしか呼ばれない deep_cluster/ の中身は、ノード内のハード検出と NUMA バインド（CPU とメモリの割り当て）だけ KV の照合・取得・転送は、公開エンジンの外側にあります。 出したものと、出さなかったもの 出した部品 出さなかった層 FlashMLA / DeepEP / DeepGEMM（vendor/ に同梱） KV キャッシュのシステム（3FS の上で照合・TTL（保持期限）・削除を担う層） C++ スケジューラ、EPLB（自前実装） P/D 間の転送路と上位の振り分け TileLang カーネル（CUDA と Ascend の 2 系統） DP レプリカ間の負荷分散 3FS（2025-02 公開。コードからは参照しない） 自動伸縮・障害時の再構成 3FS は DeepSeek の分散ファイルシステム、EP はエキスパート並列（MoE のエキスパートを GPU に分けて置く方式）、EPLB はその負荷を均す配置の仕組みです。部品も社内と同一ではなく、公開版 FlashMLA は decode カーネルが社内版より 5〜10% 遅いと Q&A にあります。 2025 年に挙げた 3 つの理由 DeepSeek は 2025-04-14 にも、推論エンジン全体の公開を見送っていました。理由は次の 3 つです。 1 年以上前の vLLM フォークを元にしていて、乖離が大きい "including cluster management tools" を含む社内基盤と結合している 大きな OSS を保守する余力がない 2026 年版はエンジン単体に切り出して出しました。今回出せた理由の説明は見当たりません。境界は固定でもなく、Q&A は今後の推論コードも DeepInfer で継続して公開すると書いています。 外した層は、計算資源の不足を運用で吸収する層に見える DeepSeek は計算資源の制約への対策を運用層に集め、そこが社内インフラとの結合点になった、というのが私の読みです。 制約はチップの禁輸 制約の出どころは米国の輸出規制です。2022-10 の規制で NVIDIA は対中版の H800 を出しましたが、2023-10 の改定で H800 も対象になりました。2025-04 には H20 にも許可が要ると通知され（NVIDIA の 8-K）、2025-12 に H200 の販売を認める方針が出ています。 創業者も 2024-07 に、問題は資金ではなくチップの禁輸だと語っています（ChinaTalk の英訳）。 制約はモデルと運用の両方に出ている V3 の技術報告（2024-12）では、学習は H800 2,048 枚です。NVLink（160 GB/s）と IB（50 GB/s）の帯域差を踏まえ、各 token の送り先を最大 4 ノードに制限しました。 運用側にも似た発想が見えます（2025-03-01 の推論システム概要）。 全サービスが H800。昼は全ノードで推論し、夜は縮めて研究と学習に回す ピークは 278 ノード、平均は 226.75 ノード 24 時間の入力 token のうち 56.3% が、ディスク上の KV キャッシュに命中 文書は配分の理由を禁輸とは書いておらず、限られた台数を時間で使い回す工夫と読むのは私の推測です。 ディスクの KV は 2024-08 に料金表にも現れ、キャッシュ命中は最大 90% 安くなりました。 2026 年の Q&A では KV 専用の 3FS が約 100 PiB あり、冗長化は 10+2 の消失訂正符号（データ 10 に検査用 2 を足す方式）です。2024 年の論文のミラー構成（20 PiB 超）とは用途の違う別クラスタなので、単純には比べられません。 容量コストへの対策だろう、というのは推測です。 停止時の KV ごとの移送や故障時の再構成も、Q&A にはあってもコードにはありません。 部品は出し、運用層は残した カーネル、通信、EP、スケジューラ、3FS といった部品は公開され、その上で台数・配置・料金・TTL を決める運用層は残りました。 もう一つの仮説です。DeepInfer は NVIDIA と Ascend 950 の両方で動き、Q&A の設計目標の 1 つ目も「複数ベンダーのチップ」です。 そのためにハード依存の部分をカーネルに閉じ込め、運用層から切り離す必要があったことが、エンジンを切り出す圧力になったと推測します。「国産チップのために公開した」とは DeepSeek は言っていません。 閉じた層に乗るのは、計算資源の希少さ 制約は価格にも出ています。2026-04-24 の V4 の発表で DeepSeek は、高性能な計算資源が足りず V4-Pro の処理量に限りがあり、Ascend 950 の超節点が量産されれば大幅に値下げすると述べました（財聯社の引用による）。2026-08 にはピークとオフピークで料金を分けています。 ただ、運用層を閉じるのは DeepSeek に限りません。地政学が決めているのは閉じるかどうかではなく、閉じた層に何が埋め込まれるかで、DeepSeek ではそれが計算資源の希少さだと私は読んでいます。 OpenAI は逆に、結合を一か所に集めた OpenAI も運用層は出していません。逆なのは結合の置き方で、ハードの層の結合はほどき、状態と制御の層に集めました。 Habitat: 負債と知りつつ一か所に寄せる OpenAI の社内ストレージ基盤 Habitat は、約 40 地域、毎秒 7,000 万件超、500PB 超の規模です（2026-09-11 の記事）。 始まりは DevDay 2023 の、単一の DB につながる Python クライアントライブラリでした。のちにサービスに集約し、アクセス制御・監査ログ・ストレージへのアクセス制限を一か所で効かせられるようにしています。これを本人たちは戦略的に引き受ける技術的負債と呼んでいます。 ChatGPT の DB も、単一プライマリの PostgreSQL と約 50 のリードレプリカです（2026-01-22）。Habitat の背後は Azure Cosmos DB、PostgreSQL も Azure の管理サービスで、状態の層の足場はまだ Microsoft の上にあります。 ハード層は多重化して広げた チップの調達先は、DeepSeek と同じく複数ベンダーに広げました。学習と推論の大部分はなお NVIDIA だとしつつ（2026-03）、AMD（6GW）、Broadcom（自社設計 10GW と推論チップ Jalapeño）、AWS Trainium（2GW、GeekWire）、Cerebras（750MW、TechCrunch）と組んでいます。 Microsoft の独占も、優先交渉権への後退（2025-01）、その廃止（2025-10-28）、全製品を任意のクラウドで提供可（2026-04-27）の 3 段階でほどけました。 提供サービスの線は「状態を持つか」で引かれたように見える 2026-02-27 の共同声明で、Azure は「stateless な OpenAI API」の独占クラウドのままとされました。同じ時期に Amazon とは、Bedrock 上で記憶や権限を保持する「stateful runtime」を作ると報じられています（InfoWorld、2026-02）。 契約の線が状態を持つ層かどうかで引かれた、というのが私の読みです。2026-04 の改定後もこの線が残るかは、Microsoft のブログ本文からは確認できませんでした。 顧客と政府の要件も、状態と制御の層に集まります。 データの所在地: 2026-01-16 から ChatGPT Enterprise などで米国か欧州の地域内で推論 ゼロデータ保持（ZDR）: /v1/files など状態を持つエンドポイントは対象外 FedRAMP 20x Moderate（米連邦政府向けクラウドの認証、2026-04-27） 国防総省との合意（2026-02-28）: cloud-only で、安全の仕組みは OpenAI が自社で運用 出しているのは、重み（gpt-oss、2025-08）と運用記事と障害報告です。配信・安全・ストレージのスタックは出しておらず、境界の説明も見つかりませんでした。状態と制御の層こそ売っている部分なので出さない、というのが私の推測です。 制御面については、OpenAI 自身が政策の側から求めてもいます。2025-03 の OSTP（米大統領府の科学技術政策局）への意見書で、米国が最も優遇する国々（輸出規則の Tier I）のデータセンターに、Tier I の国に本社を置く企業による支配と、運用への不正アクセスの防止を求めました。これは OpenAI の提案で、課された条件ではありません。 何を出せるかも契約で縛られています。2025-10 の Microsoft との契約では、オープンウェイトの公開に能力基準（中身は非公開）が付きました。輸出・政府販売・提携の三方から、制御面を手元に置く動機が重なっている、と私は読んでいます（推測）。 OpenAI の閉じた層に埋め込まれているのは、所在地と統制の要件です。 Mooncake は、結合部分そのものを外に出した Moonshot（Kimi の開発元）の Mooncake は、DeepSeek が残した層のうち、KV の転送・保存・索引を公開しています。 Transfer Engine（2024-11-28）: RDMA などで KV を運ぶ転送層 Mooncake Store（2025-03-07）: 分散 KV キャッシュのプール Conductor（2026-09〜）: cache-aware なルータ（KV が残っているエンジンへ要求を回す）が使う KV インデクサ 2024-11 の公開時から、大モデル時代のストレージの「标准接口」（標準インタフェース）と参考実装を目標に掲げていました（量子位、2024-11-28）。その後 vLLM・SGLang・TensorRT-LLM・Dynamo・llm-d にコネクタが入り、2026-02-12 に PyTorch Ecosystem に加わっています。 担い手は Moonshot だけではない 2024-11 の公開は、清華大学の研究室と Moonshot が主導する産学の共同開源でした。 MAINTAINERS.md の codeowner 4 人は Alibaba Cloud の 2 人と清華系の 9#AISoft・趋境科技の 2 人で、Moonshot 所属はいません。git 履歴の社用メールでも Alibaba 259 件、tencent.com 114 件に対し、moonshot.cn は 2 件です（全 2,480 件。個人メールが大半）。 Alibaba は Moonshot の大口株主で（2024 年時点で約 36%、SCMP の報道）、Tencent も 2024-08 の調達に参加しました（Bloomberg）。どちらもクラウドを売る側で、Alibaba の tair-kvcache と Tencent の FlexKV は Mooncake に対応しています。標準になれば自社クラウドの得になる、というのは推測です。 契約と測定は、後から足した押さえ 公開の理由と商流の押さえは、時期が違います。コードを出した 2024-11〜2025-03 に見える理由は、共同開発・標準狙い・株主のクラウドです。商流の押さえは、その後に足されました。その後も KV インデクサ（Conductor、2026-09〜）の公開は続いていて、出すものと押さえるものを並行させている形です。 測定（2025-09〜）: Vendor Verifier は、Fireworks や Together などの第三者 API のスコアを公式と並べて公開する 契約（2026-07）: Kimi K3 License は、12 か月の売上が 2,000 万ドルを超える MaaS 事業者（モデルを API で提供する事業者）に、商用利用の前に別契約を求める ブログには "Weights are open. The knowledge to run them correctly must be too." とあります。運用の知識は開き、品質と商流はライセンスと検証で押さえる形です（推測）。 Moonshot では地政学の影は薄く見えます。国務院の「人工智能+」の意見（2025-08）は開源を奨励していますが、Mooncake の公開はそれより前で、政策が後押しした証拠は見つかりませんでした。 置き場所を決めるのは、お金と責任の流れ ラボ 結合の置き場所 出したもの 出さないもの 乗るお金と責任（推測） DeepSeek 運用層（KV・負荷分散・伸縮） カーネル、通信、エンジン単体 KV システム、P/D、DP 負荷分散 キャッシュ命中の料金、ピーク料金、処理量の上限 OpenAI 状態と制御の層 重み（gpt-oss）、運用記事、障害報告 配信・安全・ストレージのスタック クラウド契約、データ所在地、FedRAMP、政府契約 Moonshot 契約と測定（公開の後に追加） 転送・KV ストア・KV インデクサ（2024-11〜） 本番との差分（同じかは不明） MaaS の売上条項、提供品質の検証 どの社も、お金と責任が乗る層は手元に残しているように読めます（Moonshot は運用層を出した後に、契約と測定を足しました）。乗るものの中身には地政学が入り込み、DeepSeek では計算資源の希少さが料金と処理量に、OpenAI では所在地と統制の要件が契約に表れています（推測）。 DeepSeek は 2026-06〜07 に初の外部資金を受け、7 月 15 日の登記変更で国家人工智能产业投资基金が直接の株主になりました（財聯社、2026-07-15）。持分は約 0.28% と小さく、これだけで国家の関与が強いとは言えません。上場の準備も報じられています（Reuters 経由の The Star、2026-10-22）。 時系列だけ確かめておくと、2025-04 の見送りは外部資金の前、DeepInfer の公開は外部資金の後で上場準備の最中です。資金が公開の判断を左右したことを示す材料はありません。 一方、2026-09-10 の発表では "2,000 GPUs + a storage cluster? Let's talk." と呼びかけています。運用層は全員には出さず、規模のある相手とは個別に組む道を残している、と読んでいます（推測）。 業務システムの密結合は業務要件から生まれます。AI 基盤の密結合は、モデルとハードの事情から生まれる面が大きいように見えます。そう考えると、結合の位置がチップと料金の事情に引っ張られるのも自然です（推測）。 まとめ 公開の境界は秘密主義の度合いではなく、結合をどこに置いたかという設計の結果として読める DeepSeek は運用層に、OpenAI は状態と制御の層に結合を置いた。Moonshot は運用層を共同体で出し、後から契約と測定を足した その置き場所は、お金と責任が乗る層に重なる 地政学が効くのは閉じるかどうかより、閉じた層に何が埋め込まれるか（DeepSeek は計算資源の希少さ、OpenAI は所在地と統制の要件） 次のリリースや技術ブログでは、次の 5 つを確かめてみてください。 どの層が欠けているか、前回から動いたか（README の「含まれないもの」の欄） フックや設定の跡はあるか（空実装、外から注入する口、tests からしか呼ばれない関数） 誰が保守しているか（MAINTAINERS、コミットのメールドメイン） ライセンスと測定で何を押さえているか（売上条項、認定パートナー、検証ツール） 閉じた層にどの制約・要件が乗っているか（チップの調達、データの所在地、政府との契約） 今回出せた理由、出さない層の意図、地政学の効き方の解釈は、各社の明言ではなく私の推測です。 参考リンク DeepSeek DeepInfer（README） DeepInfer の Q&A 文書（doc/inference_deployment_qa.md） llm_engine.py（仮想関数の箇所） The Path to Open-Sourcing the DeepSeek Inference Engine（2025-04-14） Day 6: V3/R1 Inference System Overview（2025-03-01） DeepSeek-V3 Technical Report Fire-Flyer AI-HPC（SC24） Context Caching on Disk（2024-08-02） 財聯社（2026-04-24、V4-Pro の処理量の制約と値下げの条件） V4-Pro の GA とピーク・オフピーク料金（2026-08-13） V4.1-Flash の発表（2026-09-10） NVIDIA 8-K（2025-04、H20 の輸出許可） ChinaTalk: DeepSeek CEO インタビュー英訳（2024-11-27） 財聯社（2026-07-15、株主の変更） The Star / Reuters（2026-10-22、追加調達と上場準備） OpenAI 10 億人超の ChatGPT ユーザーを支えるオンラインストレージの急速な拡張（Habitat、2026-09-11） PostgreSQL を拡張して 8 億人の ChatGPT ユーザーに対応（2026-01-22） OpenAI raises $122 billion（2026-03-31） OpenAI and Broadcom unveil inference chip（2026-06-24） AMD and OpenAI（2025-10-06） Microsoft: The next chapter of the Microsoft–OpenAI partnership（2025-10-28） Microsoft and OpenAI joint statement（2026-02-27） The next phase of the Microsoft–OpenAI partnership（2026-04-27） InfoWorld: OpenAI launches stateful AI on AWS（2026-02） Your data（データの所在地と ZDR） Introducing data residency in Europe（2026-01-16 の追記） OpenAI available at FedRAMP Moderate（2026-04-27） Our agreement with the Department of War（2026-02-28） OpenAI の OSTP への意見書（AI Action Plan、2025-03-13、PDF） gpt-oss Moonshot / Mooncake Mooncake（README） Mooncake MAINTAINERS.md Mooncake 論文（arXiv 2407.00079） 量子位: Mooncake の共同開源（2024-11-28） Kimi K3 License Kimi-Vendor-Verifier Kimi Vendor Verifier（ブログ） SCMP: Alibaba の Moonshot 持分 BNN Bloomberg: Tencent が Moonshot の調達に参加（2024-08-05） Alibaba tair-kvcache（Mooncake をストレージに使える） 国務院「人工智能+」行動の意見（2025-08-26）

ANOLISA in Action — Verify Skills, Observe Every Decision · Deploy on Alibaba Cloud ECS — full setup guide in the docs: click.alibabacloud.com · Or run it yourself: open source at alibaba/anolisa — give it a Star⭐️ if you like it. t.co