大语言模型的兴起，正在催生一场深刻的范式变革。ChatGPT、DeepSeek等生成式大模型的出现，取代了传统的搜索引擎的生态位，让普通人更倾向于使用它们代替传统搜索引擎获取想要的信息和答案。研究者们则看重了LLM的能力，为其构建了外部框架从而创造了Agent。Coze等面对非专业人士的低代码AI智能体开发平台的出现极大的降低了Agentic AI的开发门槛，爱好者们只需要经过较少的学习就能亲自开发自己的Agent。基于LLM的Agentic AI正从科幻走向现实，它们不再是被动等待指令的工具，而是能自主规划、推理并执行复杂任务的实体。不过我们似乎都被带入了一个理想的歧途：一些提示词、一堆工具、一个工作流就能搞定一切，创造一个无所不能的Agent。
几乎所有的刚开始构建Agent的专业团队，第一步都是使用LangChain、AutoGen等框架构建模型。构建速度很快，产品看起来很美好。但随之而来的却是一个80%陷阱：一个能获得80分的Demo，当你想把它优化到能够真正落地的99分时，却发现这比推倒重建还困难。这还不是最致命的，当行业为不断出现的能力更强、参数量更大的新版本大模型欢呼时，Agentic AI的开发者们却陷入了一个噩梦：由于AI智能体过于依赖自然语言提示，模型的改变有时会给Agent带来负优化。大量开发者突然发现：精心打磨的提示词在新版本中完全失效，新的模型的输出风格、逻辑结构甚至答题习惯都发生了变化，每次升级都意味着成百上千条特设的关键词的重新修改。 学术界甚至已经创造了一个新词：Prompt Migration（提示迁移）。这不是模型本身能力的倒退，而是依赖提示词工程这种脆弱的特设式的产品构建方式的全盘崩裂。这不是模型的错，而是方法论的死结：当前AI智能体的涌现正伴随着工程的缺失。
当我们兴奋地构建这些强大的智能体时，却发现我们正陷入一场提示词软件危机：AI智能体系统依赖脆弱的自然语言提示，核心的逻辑却隐藏在黑箱之中。面对提示词软件危机，一些研究者试图一遍遍的推出新的“提示词最佳实践”指南：给大模型更长的指令，更多的示例，强化System prompt来约束模型行为。这些方法短期内能缓解症状，但始终没有触及到问题的核心：承认自然语言提示的脆弱性。另一些研究者尝试使用传统的软件工程方法来弥补工程上的缺失。然而，传统的软件工程方法在面对Agentic AI系统时遇到了前所未有的挑战：在Agentic AI范式下，系统的目标、结构与反馈机制在设计时即可被完整建模并保持稳定已不再成立。正相反，Agentic AI范式的核心是系统在运行时动态生成其目标和行为。这种设计时与运行时的根本区别，最终导致传统软件工程方法
在面对提示词软件危机带来的挑战时，显得力不从心。由于工程化方法的严重缺位，当前构建的智能体普遍表现的脆弱、不透明且无法从经验中演化。
我们认为，行业迫切需要一套专为Agentic AI时代设计的，全新的系统性软件工程框架。为此，我们提出了一个由三大方法论构成的综合性工程框架，并将其工程化为一个移动GUI智能体Fairy,以证实其有效性。
在本篇以及接下来的两篇文章中，我们将完整分享我们在Agentic AI系统的工程化框架及方法方面的一系列思考和实践。
问题篇：我们将深入剖析提示词软件危机的三大核心缺陷，并说明为什么Agentic AI系统面临独特的工程化挑战。
理论篇：我们将详细拆解提出的三大方法论，并说明它们如何解决鲁棒性、可观测性和可演化性的挑战。
实践篇：我们将以Fairy为蓝本，展示这套框架如何在真实的Mobile GUI Agent上落地。
在本系列的第一篇中，我们将首先深入剖析：提示词软件危机带来哪些挑战？已有的研究与实践在Agentic AI软件工程方面进行了哪些尝试？
何为提示词软件危机？
当前，大多数 Agentic AI 的开发仍停留在特设（ad-hoc）式、以试错为主的构建模式中。这种模式由于缺乏系统化的软件工程约束，导致智能体表现得极不稳定、难以观测、调试与维护，无法满足生产级应用的要求。Agentic系统依赖脆弱的自然语言提示，其核心逻辑与行为被隐藏在语义生成的“黑箱”中。这一现象，我们称之为提示词软件危机。
这与上世纪软件危机中的代码复杂度失控类似。当下的挑战主要集中于语义复杂度失控：工程师缺少必要的工程手段来预测、设计并约束系统的行为。
提示词软件危机带来哪些挑战？
01
鲁棒性差
非确定性是大型语言模型的天然属性。在缺乏严格工程约束的情况下，这种不确定性会被进一步放大，最终让系统表现出难以控制的行为。具体体现在两个层面：
宏观规划发散：面对需要长链推理的复杂任务，如果没有明确的知识边界和结构化约束，智能体往往会依赖自身的通用预训练知识来规划。这种规划方式极易偏离主线从而导致任务可靠性迅速下降。
微观意图臆测：在局部解析阶段，当指令不够明确、信息不够充分时，智能体可能会自行补全缺失部分，以保持动作序列的连贯性。然而，这种“好心办坏事”的自动填补，往往偏离用户真正意图，使系统的行为不再可信。
02
可观测性不足
可观测性是现代复杂系统得以可靠运行、可调试、可维护的基础。然而，当前的Agentic AI系统整体都存在可观测性薄弱的问题，无论是单智能体还是多智能体架构：
单智能体系统：规划、决策、反思等核心能力常被封装在一个巨大且耦合紧密的组件中。其内部逻辑几乎不可见，外界只能看到输入与输出，完全缺乏对内部思考过程的观测能力。
多智能体系统：数据流与控制流交织在一起，组件之间的交互和协作逻辑往往不透明、难以梳理。
在LLM本身不确定性的基础上再叠加这种不可观测性，系统的状态、意图与决策路径都难以追踪，使其很难调试，也难以达到生产级系统对可靠性的要求。
03
自适应缺位
我们希望 Agentic AI 系统能像真实的智能体一样，随着使用持续学习和演化，但现有多数实现却几乎没有演化机制。缺乏自适应性主要体现在两个方面：
• 因为缺少工程化的规范，大多数系统对自己的决策、执行、观察记录都十分短暂、零散且不成体系。宝贵的运行时经验无法沉淀，自然也无法在任务结束后进行真正有价值的复盘与反思。
• 即使有原始经验，也缺乏将其提炼为长期可复用知识的正式流程。系统无法把一次次运行中得到的洞察转化为稳定的能力。
这种结构性与流程性的双重缺位导致智能体永远像个永恒的新手。因此不停的在同一个任务中重复类似的错误，破坏了系统通过自我演化来提升任务性能并降低边际成本的潜力。
已有的Agentic AI软件工程实践有哪些？
为应对“非确定性失控”危机，研究者尝试引入目标导向的需求工程（GORE）、分层任务网络（HTN） 及其运行时扩展 Tropos4AS。目标导向的需求工程是一种要求人类分析师在项目开始前，就必须把系统所有目标以及子目标全部定义清楚的方法论，其著名的实现有KAOS——它提供了一套高度形式化的语言，用来构建和分析这个目标模型，确保其在设计时就完备、无冲突。分层任务网络则是一种要求工程师必须提前定义好“高层任务”是如何“分解”为“具体子任务”的经典规划技术。Tropos4AS是一个试图将目标模型（如 GORE/KAOS 的产物）应用到运行时的扩展框架。可惜的是，这些理论均根植于设计时规约，无论是用于设计时实现还是运行时解释，这种预定义范式都与Agentic AI 依赖 LLM 在运行时动态生成目标的范式完全对立。这种对预定义模型的依赖，使其无法约束规划发散或意图臆测，最终在解决非确定性失控挑战上失效。
面对可观测性不足的挑战，研究者试图借鉴多智能体系统（MAS）、信念-欲望-意图模型（BDI）或MS-HTN框架（将分层任务网络扩展到多智能体场景的框架。MAS是一种定义多个智能体之间如何协同工作与通信的架构。BDI则是一种试图为单个智能体构建理性心智模型的架构。虽然这里引入了智能体这个词语，但不幸的是，这里的智能体并不是指我们今天所说的Agentic AI，而是一种符号主义智能体。符号智能体的逻辑是被严格规约、行为可预测的（即其行为完全由工程师显式编码）。而我们所面对的基于大模型的智能体，其决策逻辑是涌现的。用可预测行为的框架，去管理或约束逻辑涌现的智能体，强行套用旧的规约反而会扼杀其自主性。因此，这些传统架构无法为认知耦合的黑箱或数据流-控制流耦合提供有效的解耦方案，在应对可观测性不足挑战时捉襟见肘。
最后，为应对自适应性缺位挑战，MAPE-K控制循环似乎是理想方案。MAPE-K（Monitor-Analyze-Plan-Execute over Knowledge，即监控-分析-规划-执行-知识循环）是一个经典的自适应控制模型。它允许系统参照一个K知识库，对环境变化做出确定性的调优。然而，传统MAPE-K 的核心是自适应而非自演化的，其K库是静态的，由人来维护。即便是那些试图通过Models@Runtime (M@R) 范式（一种主张知识库本身也应该是一个在运行时可被更新的动态模型”的尝试）也只是将K库从静态文件变成了动态的结构化模型。因此，无论是传统静态的k库还是M@R的动态结构化模型，这些框架都缺乏一个真正的学习流程。它们无法处理LLM产生的短暂易失而非结构化的认知堆栈，更无法将其固化为可复用的知识，使其无法解决自适应性缺位挑战。
我们的答案：一个系统性的Agentic AI软件工程框架
这些传统的理论失效证明，我们迫切的需要一个专门为Agentic AI时代设计的全新软件工程框架。为应对提示词软件危机和传统软件工程方法局限性带来的挑战，我们提出了一个综合性的软件工程框架，旨在系统性的解决上述三大危机。该框架三个相辅相成的方法论构成，每个都精确地对应一个核心问题。我接下来会在理论篇详细拆解提出的三大方法论，并说明它们如何解决鲁棒性、可观测性和可演化性的挑战；在实践篇以Fairy为蓝本，展示这套框架如何在真实的Mobile GUI Agent上落地。