构建Agent可操作的系统

Image generated by Google Gemini

如果你让AI Agent做重构结果应用崩了，如果你想把遗留系统转变为AI可以工作的环境，如果你想把Fortune 500的遗留维护预算转变为转型预算——这篇文章就是那份路线图。

锁死的记忆

IT泡沫时代，企业开始积累数字资产。代码、数据库、规格说明、文档、API——数十年积累的企业记忆。

那些记忆被锁死了。无法搜索、无法验证、不可达(unreachable)。除了人亲自阅读、亲自理解、亲自修改，别无他法。所以企业 IT预算的60~80%都花在维护这些锁死的记忆上。打不开，只能守着。

我们正处在所谓AI泡沫的正中央。这个时代的真正含义不是模型变聪明。而是企业长期锁死的legacy记忆正在变得可达(reachable)。

但还没有。2026年，AI agent写代码。68分钟烧掉数百万token，完成重构。应用彻底崩溃。这样的故事每天都出现在X上。

为什么一再重复？

不是因为agent蠢。而是环境不适合agent工作。你不能把机器人放进人类办公室。你得建造机器人能工作的工厂。

要解锁锁死的记忆，记忆必须先变成可以被打开的形态。这不仅是代码的问题。数据库、规格说明、文档、API——企业的整个数字资产对agent都是不透明的。

什么是Agent-Operable

agent要自主工作，需要三个条件：

1. 必须可读——没有噪声

在2,000行文件中找一个函数，1,950行都是噪声。在未规范化的数据库中找客户信息，得join三张表。藏在Excel里的业务规则，agent根本发现不了。

可读不是指人能读。而是指机器能结构化地解析。

2. 必须可验证——机械地

agent修改后如果不知道什么坏了，就会陷入doom loop。代码需要测试，数据库需要约束，API需要schema验证，规格说明需要交叉验证。

让LLM验证LLM，就像问你喝醉的朋友"我醉了吗？"。go test不会产生幻觉。CHECK约束不会说谎。JSON Schema不会漂移。

3. 状态必须持久化——即使agent死了

agent一定会崩溃。token限制、网络错误、会话断开。如果进度没有保存，每次都从头开始。

agent A处理到第200个函数然后死了，agent B必须从第201个接着来。agent是一次性的，但进度必须累积。

第零步：把bug冻结

三个条件是目的地。起点不同。没有文档、没有测试、300个2,000行的文件。这才是起点。

在这种状态下让agent"重构"，会怎样？它会"修复"一个十年前的bug。问题是，那个bug不是bug。

Hyrum’s Law：一个足够老的API的所有可观察行为，都有人依赖。放置十年的小数四舍五入错误，VIP客户的支付逻辑绑在上面。日期解析bug催生的Excel宏支撑着整个财务部门。老bug是隐性的业务规格说明。

agent的第一个任务不是修代码。而是冻结当前行为。

戳API。记录响应。把响应固定为Hurl测试。奇怪的bug还是预期行为——不区分。原样冻结。这是ratchet的第一个齿——锁住agent，不让它擅自"改进"。

变更只由持有规格说明的人决定。agent是执行者。不是裁判。

冻结完成后，才开始向三个条件——可读、可验证、可持久——转变。

不仅是代码

“Agent-operable codebase"是起点。企业的数字资产不仅是代码。

单独看每一行，都是"应该整理一下”。合在一起看，是一个系统。

Symbolic Feedback Loop

一个共同结构使这种转变成为可能。

LLM生成 → 确定性工具判定 → 结果反馈给LLM → 重复

在代码中、测试中、规格说明中、数据中——同一个循环在运作：

代码结构：    filefunc validate → 违规反馈 → LLM修复 → 重复
测试：       go test + coverage → 未覆盖行反馈 → LLM补强 → 重复
规格一致性：  yongol check → 漂移反馈 → LLM修复 → 重复
用户规则：    rulecat evaluate → 违规反馈 → LLM修复 → 重复

LLM参与的只有"生成"。修什么、是否通过、下一步是什么、是否结束——全部由机器决定。不给LLM判断权。

这不是发明。秀丽隐杆线虫(C. elegans)将302个神经元中的60个(20%)用于感觉输入。用于验证，而非生成。5亿年进化得出的结论：提高反馈质量比增加神经元更有利于生存。

业界在让火车（模型）跑得更快。更大的模型、更聪明的agent、更好的prompt。但火车越快，铁轨越重要。

80/20

最终状态下，系统分为两层。

SSOT (80~90%)
├── OpenAPI, DDL, SSaC, FuncSpec, Rego, Hurl, React TSX, Mermaid, manifest
└── 从规格说明生成。漂移从源头杜绝。agent自由修改。

Custom (10~20%)
├── 业务规则、领域逻辑、法律/政策计算
└── 用filefunc结构化，用tsma确保测试。人工确认。

人真正需要关注的代码压缩到10~20%。其余由agent读规格说明生成，由机器验证。

企业的60%

企业 IT预算的60~80%消耗在legacy维护上。开发者42%的时间花在技术债务上。手动legacy迁移的70%以失败告终。

这笔预算已经在花了。不需要新预算。只需改变方向。把维护预算变成转型预算。

把legacy整体输入，agent-operable系统就会输出。这就是Building Agent-Operable Systems的承诺。

为什么大厂不做这个

Anthropic和OpenAI做通用模型。模型提升10%，所有客户都受益。但做一个Go test反馈循环，只有Go开发者受益。做一个Python coverage工具，只有Python项目受益。

符号验证本质上是领域特化的。每种语言、每个框架、每种规格说明都需要不同的验证器。没有通用性，就不符合大厂的ROI。

所以这个位置是空的。造火车的人和铺铁轨的人不是竞争关系。是互补关系。

问题

你的agent写代码。但谁来确认代码是对的？

另一个agent？还是go test？

你的LLM真的读了全部100,000行吗？

还是假装读了？

agent时代需要的不是更聪明的agent。而是agent能工作的系统。

Sources

• Gartner, “IT Budget and Cost Optimization” — 60–80% of enterprise IT budgets consumed by legacy maintenance
• Stripe & Harris Poll, The Developer Coefficient (2018) — 42% of developer time spent on technical debt
• McKinsey & Company, Why do most transformations fail? (2019) — ~70% of digital transformation projects fall short of goals
• Hyrum Wright, Hyrum’s Law — “With a sufficient number of users of an API, all observable behaviors of your system will be depended on by somebody”
• Winters, Manshreck, Wright, Software Engineering at Google (O’Reilly, 2020) — Formal book source for Hyrum’s Law
• White et al., “The structure of the nervous system of C. elegans”, Phil. Trans. R. Soc. Lond. B 314 (1986) — 302-neuron connectome
• Inglis et al., The sensory cilia of C. elegans, WormBook (2007) — 60 sensory neurons (~20% of total)
• METR, Early-2025 AI Developer Productivity Study (2025) — AI tools made experienced developers 19% slower, yet developers perceived 24% speedup
• GitClear, AI Copilot Code Quality 2025 (2025) — 211M lines analyzed, refactoring down 60%, copy-paste code up 48%
• Mehtiyev & Assuncao, Beyond Resolution Rates (2026) — 19 agents, 9,374 trajectories; 12.4% of total compute spent on zero-yield tasks