ASys（Agentic System Interface）是一个专为 AI Agent 设计的开源系统接口协议——用二进制指令替代文本命令，用长连接替代每次重新握手，用指令级权限替代宽泛的会话权限。这篇文章讲的是它从哪里来，为什么这样设计。
去年用 Claude 辅助写代码，感觉像带一个记性很差的实习生。上下文一长就会开始漂移，重启 Session 要好几个回合才能找回状态，前面约好的接口后面就忘了。
今年一二月再试，用 Claude Code 写 ReCall——一个基于 PySide6 的桌面题库工具，有配置、UI、数据库、i18n、主题系统、测试，最后还要打包成 Windows 可执行文件。功能不多，但桌面程序开发该有的基本都齐了。这次感觉完全不同了：不是 AI 替我写，依然是我在主导，但 Claude 已经跟得上。说要做什么，它能准确理解；出来的代码基本能用；即使偏了，纠正一下也很快能调回来。
前后两次，AI 的进步很明显。
回头看，LLM 目前真正落地的领域：文字处理，以及开发。这两个领域有个共同点：都是做完就结束的事——一篇文章写完发出去，一个功能交付上线，这件事就画句号了。但系统的运维不一样，系统上线之后是实时的、有状态的，问题随时会来，没有"做完"这一说。那是完全不同的一个世界。
备考 A+ Core 2 那段时间，白天复习刷题，晚上写代码，脑子里一直转一个问题：AI 辅助开发越来越成熟——那运维呢？
当操作者变成了 AI
AI 把开发速度拉成指数级之后，存量的积累速度也跟着加快了。每部署一个新服务，就多了一个需要长时间甚至永久维护的对象——这就成了存量。系统不会自己消失，问题会积累，复杂度会叠加。可以这么想象下：运行中的系统整个是一个大湖，开发中的新系统是众多不断涌入的河流。随着河流的数量越来越多、河流中水流的速度越来越快，大湖的扩展速度将超过我们的想象。
但人工运维是线性的——一个工程师能维护的系统是有限的，就算是有各种工具的帮助，人工运维也跟不上指数级的积累速度。往前看，能接这个盘的只有 AI 运维。
但 AI 运维要成立，有一个前提需要解决：接口。
从 POSIX 到 SSH、从 Ansible 到 K8s Operator——这些成熟的工具，每一个都经过了大规模生产验证，在各自的场景下运转良好，还会继续运转很久。但它们的设计前提都是人类操作员。当操作主体变为 AI Agent 时，有几个问题值得从头思考：文本解析随时可能因格式变化而失效；会话级权限对可能产生幻觉的 Agent 风险太高；高频采样时每次握手的开销会成为瓶颈。
比如"猜文本"的代价。Agent 通过 SSH 执行 ps aux | grep nginx，拿到的是自由文本——格式会因 OS、locale 和工具版本而异，还得自己解析，每一段可能失效的正则表达式都是一个潜在的幻觉入口。但调用 ASys 的 SYS_PROCS 指令，拿到的是固定的 44 字节二进制帧：进程总数、top-5 PID、CPU%、内存%、状态标志——类型明确，无歧义，在每个节点上都一样。解析逻辑是一行 struct.unpack。这不只是性能问题，更重要的是可靠性的量级提升。当解析的负担趋近于零时，Agent 几乎全部的算力就可以用在真正重要的事上：感知、推理、决策。
ASys 不是要替代这些工具，只是想探索一个问题：如果专门为 Agent 设计，从第一性原理出发，接口应该长什么样？多一个选择而已。
开源地址：github.com/vincentping/asys
ASys 从哪里来
2010 到 2016 年，我在上海的一家智能卡公司做开发——SIM 卡、银行卡、身份证芯片。那个行业有一条铁律：卡发出去了，没法收回。
智能卡的开发流程是先写规范，基于规范开发，基于规范测试：功能测试、异常测试、边界覆盖……内部测试完了，还要去电信服务商进行现场测试。繁琐、周期长，但没有别的选择：产品一旦量产出去发现 bug，召回成本是灾难。这和互联网的"边跑边迭代"开发风格，是两种完全不同的哲学。那六年给我留下最深的东西不是某项技术，而是一种本能：把事情想清楚写清楚，比快速动手更重要。
那六年也让我对很多协议很熟悉，尤其是 ISO/IEC 7816，智能卡通信的 APDU 体系。读卡器向智能卡发二进制指令，拿到固定格式的响应，不需要经过人眼，也从不解析文本。返回 0x9000 就是成功，返回 0x6982 即 Security status not satisfied，几十年没变过。这套协议覆盖了全球数百亿设备——每一张银行芯片卡、每一本电子护照、每一张 SIM 卡。它的每一个边界条件，都经过了最严苛的实战验证。
2016 年之后，我离开了智能卡行业，后来一直在做各种大大小小的网站系统——前端 JS、后端 Python/Go/Java，数据库、服务器、缓存、各种云、各种架构。
过去一年多又一直在学习 AI，并尝试用 Claude 开发各种项目。随着对 AI 越来越了解，我逐渐相信：AI 会像工业革命一样彻底改变人类的走向。所以，当我完成 ReCall 这个项目后，我就一直在思考做点什么与 AI 相关的事。
有天晚上，我记得是二月底，复习得很晚了，刚躺下，迷迷糊糊的，脑子里突然冒出了 7816 的 APDU——那些自带美感的二进制指令，固定格式的响应。我一激灵坐了起来：对呀，为什么不用 APDU 的方式让 Agent 和服务器沟通呢？还要把人类的文本加在中间干嘛？
当晚就把 7816 协议下载下来重新翻了一遍，写了个简单的文档，把初步想法记下来。
智能卡那六年、网站系统那十年、加上这一年多的 AI 实践——缺了哪一块，都不会在那个迷糊的夜晚把这几样东西联系起来。智能卡的老同事们大多还在嵌入式的世界里；做网站系统的朋友又很少有底层协议设计的背景。也许这就是人们说的，多样性带来涌现。有了这个 idea 不试试可惜了。
三个月，从零到开源
今年三月初，A+ Core 2 还没考完，我就开始动手了。
按智能卡时代养成的习惯，先写文档。从接口设计哲学，到指令集编码，到安全模型，到帧格式，每一块想清楚再写，写着写着发现没想清楚，回去再想。3 月 16 日，文档 v0.1 出来，同一天第一个 PoC 在 Windows 机器和 RHEL 服务端跑通：SYS_HELLO 指令，返回 0x9000 OK。
等到考试考完，项目推进就加快了，文档和代码交替迭代。写代码，发现设计有问题，回去改 spec，再继续。不是推倒重来，是不停打磨。
这个过程里有几个决策点，每个都卡了一段时间。
传输层：为什么不用 mTLS
传输层是第一个让我卡住的地方。本能反应是 mTLS，行业常见方案，用的人多，出了问题好查。但越想越不对。
asyd 是 ASys 协议的服务端 Daemon，核心用途之一是在系统 OOM、磁盘满这种极端情况下还能用——恰恰是最需要它的时候。如果这时候因为证书过期、CA 连不上而失联，一个在急救时刻失联的接口，比没有接口更危险。而且 OpenSSL 是重量级依赖，和零外部依赖的设计目标根本冲突。
最终选了 Noise Protocol IK，基于 Monocypher 实现。纯密码学原语，无证书依赖，实现约两千行 C，可以完整审计，1-RTT 握手。这个选择让 asyd 可以做到单一静态二进制，任何 POSIX 环境都能部署，不带任何运行时风险。
权限模型：让不该存在的东西真的不存在
权限这块卡得更久。最直觉的方案是 ACL 规则表——哪个 Agent 能做什么，配置里写清楚。看上去简单，但不够。
传统安全模型（SSH/sudo）是为人类操作员设计的——人的操作是探索性的，意图难以预先声明，"宽泛默认权限 + 负向拦截"符合人类的工作方式。但当操作主体变为 AI Agent，这个假设不再成立：Agent 的行为是程序化的，权限边界完全可以在部署时精确声明。
所以 ASys 可以反过来：系统对 Agent 是一片漆黑，只有在 Capability Map 中显式点亮的指令才"物理存在"。Agent 没被授权的操作，不是"你没权限"，而是"这个指令在你的世界里根本不存在"——未注册的指令在解包阶段直接丢弃，不进入任何执行流。
用位图还有一个额外的好处：防侧信道攻击。如果先查权限再查存在性，攻击者可以通过响应时间的微小差异推断哪些指令"存在但被禁用"。Capability Map 强制先查存在性——所有未授权操作的响应时间完全一致，消灭信息泄露面。
最小权限不是配置选项，是协议的物理属性。
指令集：怎么组织 256 个槽位
指令集的组织方式反而想得比较快，因为有现成的参照——APDU。
帧格式直接借鉴：[CLA][INS][P1][P2][Lc][Data][Le]。INS 字节的高位半字节作为逻辑页索引——0x00–0x0F 是 Core ISA，基础观测指令，永久锁定；0x20–0x8F 是 Standard ISA，七个功能组；0xC0–0xFF 是 Vendor Extensions，留给各领域自定义。
任何开发者看到指令码就知道分组，0x2x 一眼是 Process Control，不需要查表。
更重要的是 Core ISA 的语义锁定：核心指令一旦发布，字节偏移永远不变，新字段只能在末尾扩展。今天写的 Agent 解析代码，期望是在 50 年后的某个 POSIX 兼容系统上还有效。APDU 协议体系能覆盖数百亿设备，正是因为这种长期主义。ASys 想继承的，也是这个。
跑通 OODA
5 月底，在 RHEL 上跑通了完整的 OODA 闭环演示：RHEL 服务端运行 CPU hog 触发负载异常，位于 Windows 系统上的 Python 客户端依次调用 SYS_STATUS 发现异常、SYS_PROCS 定位进程、PROC_THROTTLE 压制、再次 SYS_STATUS 核实恢复，全程 0x9000。
那一刻的感受不是"成了"，而是"证明可行了"。
5 月 27 日，v0.3.0 开源。从三月初构思到开源，三个月。
现在在哪里
github.com/vincentping/asys 现在是 v0.3.1。
目前稳定实现：Core ISA 四条观测指令（SYS_CAPS / SYS_HELLO / SYS_STATUS / SYS_PROCS）、首批 Standard ISA 操控指令（PROC_THROTTLE / SVC_RESTART / TASK_QUERY）、完整的 Noise IK 加密通道、公钥白名单身份验证、Epoch_ID 防重放机制。
接下来最重要的是 Python SDK：面向 AI Agent 开发者，目标是能直接嵌入 LangChain、AutoGen 这类主流 Agent 框架。核心设计原则是 Agent 永远不直接操作字节层——调用结构化接口（sdk.proc_throttle(pid=1234, action="stop")），SDK 负责参数校验和二进制编译。LLM 对字节偏移天然不敏感，让 Agent 直接拼 APDU 参数是错误的使用方式。
还有一些已规划但尚未实现的功能：per-Agent 细粒度 Capability Map、审计黑匣子、链式传输。这些都在规范里，会逐步落地。
一点感受
一个人做协议，听上去有点异想天开。
协议通常是委员会的事——需要多方共识，需要大量案例输入，需要反复论证边界条件。但既然这个 idea 冒出来了，那就试试吧。一个人做的好处是决策可以很快，坏处是没有外部压力强迫你把每个角落想清楚。
我的应对方式是：文档比代码优先。白皮书、规范文档、设计 Notes、实施 Notes，这些花了我比代码多得多的时间。因为文字是最好的思维工具——写不清楚，说明想不清楚；想不清楚，代码写出来迟早要推倒。这是智能卡那六年给我的东西，在这个项目里用上了。
ASys 是一个探索性项目，不是 SSH 的替代品，不是 Ansible 的竞争者。它试图填的空白是：当 Agent 需要高频、低延迟、可审计地操控系统，且要在极端场景下保持接口可用时，目前没有一个专门为这个场景设计的标准化方案。
值不值得解决，见仁见智。但我认为，随着 Agent 越来越多地进入生产系统，"Agent 和系统之间的接口应该是什么样的"是一个值得认真对待的问题——不应该只是在 SSH 上套一层 LLM 就算了。
如果 ASys 能引发一些这方面的讨论，已经足够。
对了，ASys 默认监听的我特意选择了 7816 端口。这是我内心对 ISO/IEC 7816 的致敬——智能卡通信协议的标准编号。每次想起这个数字，就想起十几年前那一大堆规范——7816、14443、EMV、PBOC、UICC、RSA……趴在上面研究的日子。