AI代理的成人礼:从一次性演示到必须持续运行的系统
当AI代理开始像服务器一样需要‘永不宕机’时,所有关于提示词工程的讨论都该让位于运行时可靠性——这是这一轮技术演进中最被低估的底层逻辑。
核心观点:AI代理真正的转折点不在于模型能力的提升,而在于从短期任务向长期运行的工程化转变,这要求行业重新定义可靠性、状态管理和系统架构。
过去两年里,AI代理领域的讨论几乎完全被模型能力、提示词技巧和多智能体编排所占据。开发者们热衷于展示代理如何完成复杂推理、调用工具链或自主决策,仿佛只要大语言模型再聪明一点,所有问题都会迎刃而解。然而,近期一系列来自工程师社区的真实讨论正在暴露一个更根本的痛点:当代理被要求从演示原型变成持续运行的长期系统时,整个技术栈的脆弱性就暴露无遗。这不是一个渐进式的改进需求,而是对AI代理本质的重新定义——从“展示一下”到“必须一直运行”。
这个转变的征兆在多个技术论坛上同时出现。一位独立开发者分享了他花费五个月构建的AI代理SaaS产品,核心卖点是“60秒内让代理工作”,但用户大量涌入后,他最困惑的问题却是“如何让免费用户转化为付费用户”。在评论区,更尖锐的讨论指向了代理在长时间运行后的状态保持、任务中断和重启机制——这些问题直接决定了产品能否从玩具升级为工具。类似地,在专门讨论AI代理架构的社区里,关于“固定角色vs动态生成”的争论持续升温,表面上是设计模式之争,深层却是对代理系统能否像传统服务一样具备稳定性和可预测性的质疑。
这种焦虑并非无病呻吟。有开发者明确指出,一旦代理需要跨会话、跨重启地维持状态和任务进度,问题的核心就从模型质量彻底转向了运行时可靠性。传统的请求-响应模式在这里失效了:代理不再是收到指令、生成回复、然后等待下一次调用,而是需要像守护进程一样自主运行、自我修复,并在崩溃后从正确的状态恢复。一位匿名研究者在泄露代码中描述的“KAIROS”守护进程模式,恰恰是对这一需求的直接回应——它试图让代理具备主动执行能力,而不是被动等待用户输入。这与其说是一个技术细节,不如说是一个范式转换:代理正在从用户手动的“工具”进化成自主运行的“系统”。
然而,这种进化面临着深刻的工程矛盾。一方面,长期运行的代理必须应对不可靠的底层环境:模型可能输出不一致,外部API可能超时,服务器可能宕机。另一方面,现有的开发范式几乎完全建立在“单次完美输出”的假设上。即便像Codex这样的前沿工具引入“/goal”机制来支持持久目标追踪,其底层依然依赖模型对完成条件的判断,而这种判断本身就可能出错。更激进的尝试如“SarahMemory AiOS”试图让代理在本地运行时进入类似REM睡眠的自我反思循环,但这种方式是否能够扩展到实际生产环境,仍是巨大的未知数。
反对的声音同样值得倾听。有经验丰富的架构师坚持认为,固定角色分工和明确的系统边界才是可靠性的基石。他们指出,动态生成代理看似灵活,却引入了不可控的复杂性——每次生成的新代理都可能缺乏历史上下文,导致任务退化或行为漂移。这种争论背后是对“究竟什么才是代理系统需要的简单性”的不同理解。对某些场景而言,严格定义的角色、工具和通信协议才是长期运行的保障;而对另一些场景,自适应和动态组合才是应对多变任务的关键。这种张力恰恰说明,行业还没有找到通用的最佳实践,而这正是长期运行代理工程化最大的不确定性所在。
我们还需要正视一个更尴尬的现实:很多声称“长期运行”的代理,实际上只是延长了单次会话的持续时间,并没有真正解决跨任务、跨生命周期的状态管理问题。真正的长期运行意味着代理能在不同的硬件、不同的软件环境、不同的时间点上保持认知一致性。这不仅仅是技术问题,更是设计哲学问题——我们是否应该让代理像操作系统一样拥有自己的文件系统、进程管理器和睡眠周期?还是应该让它像微服务一样,通过外部存储和事件总线来维持状态?目前这两条路径都有尝试者,但都没有形成行业共识。
从更大的视野来看,AI代理从演示到长期运行的转变,实际上是在重复软件工程历史上每一次重大范式转换的轨迹。早期的个人电脑软件是单用户、单任务的;网络服务从无状态演变为有状态;移动应用从本地数据走向云端同步。每一次转变都伴随着一波旧工具的淘汰和新架构的诞生。AI代理正在经历同样的成人礼:它必须学会如何像成熟的软件系统一样运行,而不是像一个聪明的对话玩具。Karpathy在最近的演讲中提到的“代理原生经济”,正是对这种转变的宏观解读——当代理变成基础设施的一部分,它的价值就不再取决于一次演示的惊艳程度,而取决于它能否可靠地、持续地创造价值。
对创业者、工程师和投资者而言,这既是挑战也是机遇。挑战在于:长期运行代理的可靠性问题还没有现成的解决方案,很多现有的框架和工具都是为短期交互设计的。机遇在于:谁能率先建立稳定的状态管理、优雅的故障恢复、和可预测的行为模式,谁就能占据下一轮AI应用的核心生态位。那个在微软商店发布产品的独立开发者,如果他能在可靠性上做出差异化,而不是单纯优化首次体验,或许就能找到真正的付费转化路径。
最终,AI代理的成人礼将重塑整个技术栈的优先级。模型能力仍然重要,但它不再是唯一的瓶颈。运行时的确定性、状态的一致性、系统的可观测性——这些在传统软件工程中已被充分讨论的命题,现在需要以全新的方式在代理系统中重新实现。这不是一个渐进式的升级,而是一次彻底的重构。而那些还在争论“提示词怎么写”的人,可能很快就会发现自己讨论的是另一个时代的遗留问题。
参考来源
- Built an AI agent SaaS for 5 months, launched on Microsoft Store, free users coming in — but how do I actually convert anyone to paying? - https://www.reddit.com/r/micro_saas/comments/1t7c2lc/built_an_ai_agent_saas_for_5_months_launched_on/
- Reducing IT Infrastructure Costs with Proactive AI Agent Management - https://www.reddit.com/r/secops_solution/comments/1t6ep5w/reducing_it_infrastructure_costs_with_proactive/
- Fireside chat at Sequoia Ascent 2026 from a ~week ago. Some highlights:
- The first theme I tried to push on is that LLMs are about a lot more than just speeding up what existed before (e.g. coding). Three examples of new horizons:
- 1. menugen: an app that can be fully engulfed by LLMs, with no classical code needed: input an image, output an image and an LLM can natively do the thing.
- 2. install .md skills instead of install .sh scripts. Why create a complex Software 1.0 bash script for e.g. installing a piece of software if you can write the installation out in words and say "just show this to your LLM". The LLM is an advanced interpreter of English and can intelligently target installation to your setup, debug everything inline, etc.
- 3. LLM knowledge bases as an example of something that was *impossible* with classical code because it's computation over unstructured data (knowledge) from arbitrary sources and in arbitrary formats, including simply text articles etc.
- I pushed on these because in every new paradigm change, the obvious things are always in the realm of speeding up or somehow improving what existed, but here we have examples of functionality that either suddenly perhaps shouldn't even exist (1,2), or was fundamentally not possible before (3).
- The second (ongoing) theme is trying to explain the pattern of jaggedness in LLMs. How it can be true that a single artifact will simultaneously 1) coherently refactor a 100,000-line code base *and* 2) tell you to walk to the car wash to wash your car. I previously wrote about the source of this as having to do with verifiability of a domain, here I expand on this as having to also do with economics because revenue/TAM dictates what the frontier labs choose to package into training data distributions during RL. You're either in the data distribution (on the rails of the RL circuits) and flying or you're off-roading in the jungle with a machete, in relative terms. Still not 100% satisfied with this, but it's an ongoing struggle to build an accurate model of LLM capabilities if you wish to practically take advantage of their power while avoiding their pitfalls, which brings me to...
- Last theme is the agent-native economy. The decomposition of products and services into sensors, actuators and logic (split up across all of 1.0/2.0/3.0 computing paradigms), how we can make information maximally legible to LLMs, some words on the quickly emerging agentic engineering and its skill set, related hiring practices, etc., possibly even hints/dreams of fully neural computing handling the vast majority of computation with some help from (classical) CPU coprocessors. - https://nitter.net/karpathy/status/2049903821095354523#m