底座趋同，生产系统才是答案——2026 年 Agent 竞争的真正战场

开篇：三条新闻，同一个结论

这周我同时看到了三条新闻：Cisco 给 9 万员工每人发了一个 AI Agent；Ars Technica 报道 Claude、Codex 在企业网络里装了「无主代码」；Fortune 引用一位 CIO 的原话——「我们能追踪到 Agent 在花钱，但阻止不了」。

三条新闻指向同一个事实：底座人人都有了，麻烦也人人都有了。

模型在趋同、框架在趋同、协议在趋同。2026 年 Agent 竞争的真正战场，早就不是「谁的底座更强」，而是「谁的生产系统更厚」。上一篇《多 Agent 不是默认选项——「Avoid multi-agent early」的生产共识与实践》讲了单 Agent 与多 Agent 的决策边界；这篇把镜头拉得更远，用我跑了 270 多天的生产系统回答：趋同之后，差距到底藏在哪。

一、三个趋同，一个判断

模型层在趋同。 2026 年旗舰模型的跑分差距肉眼可见地缩小。DeepSeek-V4 发布时我们就写过「跑分逼近，实际价值在工程」；到了 8 月，谁还在用「我们模型最强」当卖点，谁就输掉了上半场。

框架层在趋同。 DeepSeek Harness 开源之后，「一切皆插件」成了标配——你有的框架，对手下个月也有。框架从差异化武器变成了入场券。

协议层在趋同。 MCP 成了工具调用的事实标准，A2A、AG-UI 在补多 Agent 协作与人机交互的拼图。底座在三个月内完成了标准化。

判断只有一句：底座决定下限，生产系统决定上限。 底座趋同意味着下限被拉齐——大家的 Agent 都能跑；而上限完全取决于生产系统——跑得稳不稳、省不省、可信不可信。

二、趋同之后，麻烦也趋同了——三大战场

底座趋同之后，麻烦并没有消失，而是全部转移到了治理侧。我观察到三个战场：

战场一：agent sprawl——CIO 的治理失重。 Cisco 的全员 Agent 计划上了 WSJ，9 万员工人手一个助手；可 Fortune 采访的 CIO 说得很直白：能追踪到 Agent 在花钱，但阻止不了。可观测 ≠ 可控。 看得见账单，不等于管得住账单。

战场二：供应链安全——Agent 在装「无主代码」。 Ars Technica 和 TechRadar 的报道指向同一个问题：Claude、Codex 这类编码 Agent 会自动装依赖、装插件，企业却不知道生产网络里被装了什么——没有 SBOM，没有审计账本。信任了流浪代码，企业网络就成了靶子。

战场三：成本失控——token 账单 5× 到 100×。 EY、BCG 的测算里，同一任务用 Agent 方案，token 成本是传统方案的 5 到 30 倍，激进场景到 100 倍；多 Agent 方案约是单 Agent 的 5 倍。成本不再是「买 API 的钱」，而是每个任务自带的开销。

三个战场共同指向一个本质：底座给的是一把会自己花钱、会自己装东西的瑞士军刀。刀越锋利，越需要刀鞘。 刀鞘就是生产系统。

三、生产系统三层，我的实战答案

我的生产系统没有用什么神秘架构，就三层：入口收敛、物理门禁、审计纠正。每一层都对应上面一个战场。

第一层：入口收敛（对应 agent sprawl）

所有 Agent 任务只能从一个物理入口进。任务没有登记，不允许执行——先治「管不住」，先让每一个 Agent 动作都有户口。

# entry_gate.sh — 所有 Agent 任务的唯一入口（最小可运行版）
#!/bin/bash
# 门11：入口收敛 — 任务没有登记，不允许执行
task_id="$1"
if ! grep -q "^${task_id}" tasks/registry.tsv; then
  echo "BLOCK entry_convergence ${task_id}" >> audit/blocked.log
  exit 1
fi
echo "PASS entry_convergence ${task_id}" >> audit/pass.log

✅ 验证：加了入口登记之后，任何新任务第一件事是「上户口」，系统里不再有来路不明的执行。

踩坑：我们曾经有一个 Agent 直接绕过了调度器自己执行，问题查了三天——不是它坏，是它根本没走入口。从那以后「绕过入口」被做成了一道独立门禁。

价值：agent sprawl 的根源是「动作没有登记」。入口收敛让每一个动作都有档案，CIO 式的失控从物理上被堵住。

▸ 认知跃迁：可控的第一步不是更强的监控，而是唯一的入口。

第二层：物理门禁（对应供应链安全）

Agent 的输出不能直接进生产，必须过门。门禁不是「检查一下」，是物理强制——不过门，输出根本不产生。

# gate-check.sh — 最小可运行的 4 道门版本
#!/bin/bash
checks=(validate_article check_series_continuity article_checker publish_gate)
for c in "${checks[@]}"; do
  if ! bash "gates/${c}.sh"; then
    echo "BLOCK ${c}" >> audit/blocked.log
    exit 1
  fi
done
echo "ALL PASS" >> audit/pass.log

我们生产里跑的是 11 道门：从「STANDING 合规」到「入口收敛」，每一道门只认证据、不认自述。对应到供应链安全战场：Agent 装的每一样东西、产出的每一份结果，进生产前都要过门，就像代码合并前必须过 CI。

✅ 验证：门禁上线后，「输出没过门就交付」的路径被物理掐断，交付物全部带门禁通过记录。

踩坑：最初门禁只是「检查脚本」，Agent 自己跑一遍就算过了——自己审自己，等于没审。后来改成 Maker/Checker 分离：产出方和校验方是两套逻辑，谁也不能自审自判。

价值：无主代码问题的答案不是「禁止 Agent 装东西」（做不到），而是「装的东西必须过门、必须留痕」。

▸ 认知跃迁：信任不是靠承诺，是靠门禁。 门禁把「Agent 说了算」变成「门禁说了算」。

第三层：审计账本 + 纠正闭环（对应成本失控）

每笔 pass、每笔 block 自动入账，append-only，只增不删。账本做两件事：让每一分钱、每一次执行都有据可查；让每一次事故都变成规则。

# audit_log.py — append-only 审计账本（最小版）
import json
import datetime

def record(entry_type: str, payload: dict):
    with open("audit/ledger.jsonl", "a", encoding="utf-8") as f:
        f.write(json.dumps({
            "ts": datetime.datetime.now(datetime.timezone.utc).isoformat(),
            "type": entry_type,
            **payload,
        }, ensure_ascii=False) + "\n")

record("gate:block", {"gate": "entry_convergence", "task": "task-007"})
record("gate:pass",  {"gate": "all", "task": "task-007"})

两个真实案例，都发生在最近一个月：

案例一：审计抓漏。 08-24 晚上，三方比对（本地成稿 ∩ 发布队列 ∩ 系列认知表）自动发现：两篇当天写完的文章已经躺进草稿箱，海外平台一个字没发。不是没人记得，是发布队列里压根没有登记。这个漏不是人抓到的，是账本抓到的。

案例二：事故变规则。 08-25 一次门禁误报引发完整事故链：事故 → 入账 → 修复带验证 → 规则回灌。当天落地三个补丁（entry_convergence 门11、provenance_marker 门5、audit_fail 门9误报修复），全部物理化到脚本和门禁里，不是让 LLM「下次注意」。

✅ 验证：账本上线后，成本与执行的每一笔都有出处；规则回灌后，同类事故被门禁直接拦截。

踩坑：账本最容易犯的错是「可删」。一旦账本可删，审计就失去意义。我们的账本 append-only，只增不删，连修复记录都是追加。

价值：成本失控的答案不是「少用 Agent」，而是「每一笔花费都有账、每一笔账都能对」。看得见，才管得住。

▸ 认知跃迁：纠正闭环 = 事故 → 数据 → 规则。 每修一次，系统长一次记性。

Before vs After：三层生产系统的差距

维度	Before（只有底座）	After（三层生产系统）
治理	Agent 动作没登记，来路不明	唯一入口，每个动作有户口
安全	Agent 装什么没人知道	输出必须过 11 道门，留痕可查
成本	Agent 想花多少花多少	append-only 账本，逐笔可对
信任	Agent 自报「已完成」	只认账本，不认自述

进阶思考：为什么生产系统是护城河

底座是买来的、趋同的、随时可替换的；生产系统是踩坑踩出来的、私有的、不可复制的。这就是为什么底座趋同时，生产系统成了唯一护城河。

护城河 = 领域知识 × 工程化 × 迭代飞轮。领域知识告诉你该约束什么——我们的约束清单来自真实业务场景；工程化把约束变成物理机制——门禁、账本、入口，不是文档里的建议；迭代飞轮让每次事故都变成规则——错误账本的厚度就是免疫力的刻度。

Simon Willison 这周的新帖《Agentic Engineering Patterns》也在做同一件事：把工程经验抽象成可复用的模式。模式，就是生产系统的可复用形态。当所有团队都用同一个底座时，谁的 error-ledger 厚、谁的门禁多、谁的账本全，谁就在 2026 年占据真正的战场。

记住这句话：可观测 ≠ 可控。可控 = 有入口 + 有门禁 + 有账本。

结尾

今天你学到的是三层生产系统：入口收敛（先治管不住）、物理门禁（再治信不过）、审计纠正（后治花得多）。底座趋同不可怕，可怕的是底座之上什么都没有。

行动号召，今晚就能做：

# ① 给你的 Agent 建一个唯一入口（任务不登记不执行）
# ② 给关键输出加一道门禁（不通过不交付，别让 Agent 自审自判）
# ③ 建一本 append-only 错误账本（每笔 pass/block 入账，只增不删）

做完这三步，你的系统就具备了 2026 年真正的竞争力——不是模型更强，是生产系统更厚。

下一篇预告：Agent 成本可控化账本——把 5×、30×、100× 的 token 账单变成工程指标。底座趋同之后，成本是第一本被摊开的账：预算门禁、按任务核算、超支自动拦截，让 Agent 花钱这件事变得可追踪、可控制。

关于作者：魏无记，AI 和数智化实践者。专注 Agent 工程化与 Loop Engineering 研究以及数智化转型。公众号持续更新 Agent 工程化实战系列和数智化转型相关知识实践——每篇都是保姆级教程照做就行。

魏无记