摘要：过去50年，软件是"录音"——相同输入永远得到相同输出。AI Agent让软件变成了"现场演奏"。但这场演奏需要全新的舞台、乐器和音响系统。谁来建？
从"录音"到"现场演奏"
过去50年，所有软件本质上都是同一个东西：一组函数，通过硬编码的控制流串联起来。If, else, while, for。相同的输入，永远得到相同的输出。这是软件工程的基本契约。
这个契约让我们建起了整个数字世界。操作系统、数据库、Web服务器、部署平台、监控系统——所有基础设施都建立在一个假设之上：软件是确定性的。
然后AI Agent出现了。
控制流不再是硬编码的。模型在运行时决定下一步做什么。同样的输入，周二下午和周一上午可能得到完全不同的输出。软件不再是"播放录音"，而是"现场演奏"。
这不是一个比喻。这是一个工程现实。
五个被打破的基本假设
当软件从静态变成动态，过去50年积累的基础设施假设，一个接一个地失效。
第一，确定性失效。
传统软件的测试逻辑是：给定输入A，期望输出B。如果不是B，就是bug。但AI Agent的输出天然是非确定性的。同一个任务，模型可能选择不同的工具、不同的执行路径、不同的表达方式。你不能用assert来测试一个活的系统。
这意味着整个测试和质量保证体系需要重建。从"结果正确性"转向"行为合理性"。从单元测试转向评估框架（Evals）。
第二，状态管理失效。
传统软件的状态是显式的：数据库里的一行记录，Redis里的一个key，Session里的一个token。你知道状态在哪里，你可以查询、修改、回滚。
AI Agent的状态是隐式的：对话历史、工具调用记录、中间推理过程、记忆检索结果。这些状态分散在模型上下文、向量数据库、外部工具的返回值里。没有一个统一的"数据库"能存储Agent的完整状态。
第三，时间模型失效。
传统API的响应时间是毫秒级。超过3秒就是"慢"。但AI Agent完成一个任务可能需要几分钟甚至几小时。它可能需要调用多个工具、等待外部审批、执行多轮推理。
这意味着整个请求-响应模型不再适用。你需要异步执行、流式输出、后台任务、断点续传。HTTP的request-response范式，在Agent时代显得力不从心。
第四，可观测性失效。
传统软件的可观测性三板斧：日志、指标、链路追踪。但Agent的"链路"不是线性的。它可能分叉、回溯、循环、跳转。一个Agent可能调用另一个Agent，那个Agent又调用了第三个。调用图不是树，是图。
Datadog最新的AI工程报告显示，2026年2月，5%的LLM调用出现错误，其中60%是速率限制导致的。但更深层的问题是：当Agent出错时，你甚至很难定位"错在哪一步"。因为每一步都不是确定性的。
第五，权限模型失效。
传统软件的权限是静态的：用户A有权限X，服务B有权限Y。但Agent是动态决策的。它可能在运行时决定调用一个它"不应该"调用的工具。它可能在处理用户A的请求时，访问了用户B的数据。
这需要全新的权限模型：per-tool、per-resource、per-context的动态RBAC。不是"这个服务能访问什么"，而是"这个Agent在这个任务的这个步骤能访问什么"。
谁在建新基础设施？
意识到这些问题的人越来越多。一批新公司正在尝试为AI Agent时代构建基础设施。
Agent框架层： LangChain/LangGraph、CrewAI、Agno（前Phidata）、AutoGen、Semantic Kernel。它们解决的是"怎么把Agent组装起来"的问题——工具调用、多Agent协作、工作流编排。
可观测性层： Datadog推出了LLM Observability，Splunk在2026年Q1发布了AI Agent监控，Langfuse、Helicone等创业公司专注于LLM链路追踪。它们解决的是"Agent出了问题怎么排查"。
运行时层： 这是目前最薄弱的环节。Agent需要长时间运行、需要持久化会话、需要断点续传、需要跨重启恢复状态。传统的serverless和容器编排并不是为这种工作负载设计的。
安全与治理层： Agent的权限管理、审批门控、合规审计。当Agent能自主决策并执行操作时，"谁批准了这个操作"变成了一个必须回答的问题。
为什么80%的Agent不工作？
一个被反复提及的数据是：大多数企业的Agent项目停留在Demo阶段，无法进入生产环境。
原因不是模型不够强。GPT-4、Claude Opus、Gemini Ultra的能力已经足够完成大多数知识工作任务。
真正的瓶颈在"最后一公里"的工程问题：
- SSE和WebSocket的流式传输
- 后台执行和会话持久化
- 跨重启的状态恢复
- 可查询的结构化存储（不是五个供应商拼凑在一起）
- 等待管理员签字的审批门控
- 多渠道部署（Slack、Telegram、WhatsApp、企业微信）
这些问题每一个都不性感，每一个都是苦活累活，但每一个都是Agent从Demo到Production的必经之路。
类比：从桌面应用到Web应用
上一次这么大的范式转移，是从桌面应用到Web应用。
Web软件需要自己的运行时（浏览器）、自己的协议（HTTP）、自己的基础设施（CDN、负载均衡、云计算）、自己的开发者工具（Chrome DevTools、Webpack、React）。我们花了二十年才把这些建完。
Heroku是2007年。Kubernetes是2014年。Vercel是2015年。我们现在习以为常的基础设施，比大多数使用它的开发者还年轻。
AI Agent的基础设施，现在大概处于"2005年的Web"阶段。大家知道这个东西会很大，但运行时、协议、开发者工具都还在早期。
对中国开发者的启示
这里面有一个巨大的机会窗口。
中国的AI应用层已经非常活跃——大模型、RAG、数字人、AI客服、智能体平台。但Agent基础设施层几乎是空白。
- 有没有一个好用的中文Agent可观测性平台？
- 有没有一个支持企业微信/钉钉/飞书的Agent部署框架？
- 有没有一个符合中国数据合规要求的Agent状态管理方案？
- 有没有一个能对接国产大模型的Agent运行时？
这些问题的答案，目前大多是"没有"或"凑合用"。
但需求是真实的。当越来越多的企业开始把AI Agent从Demo推向生产，这些基础设施的缺失会变成真正的痛点。
结语
软件正在"活过来"。这不是科幻，而是正在发生的工程现实。
但一个活的系统，比一个死的系统难伺候得多。它需要新的运行时来承载，新的协议来通信，新的工具来观测，新的规则来治理。
过去50年，我们为静态软件建了一整套基础设施。现在，动态软件的基础设施建设才刚刚开始。
谁能在这个层面建出"Agent时代的Kubernetes"、“Agent时代的Datadog”、“Agent时代的Vercel”，谁就可能定义下一个十年的软件工程。
这可能是2026年最值得关注的创业方向之一。不是做又一个Agent应用，而是做让所有Agent应用都能跑起来的那层基础设施。