企业官网建设流程全解析

网站建站要多少钱,wordpress数学公式的代码,互联网营销的优点,移动应用开发和网站开发在本系列分享的上一篇《提示词软件危机——Agentic AI系统的工程化挑战》#xff0c;我们深入剖析了提示词软件危机带来的三大挑战#xff1a;非确定性失控#xff1b;可观测性不足#xff1b;自适应性缺位。我们同时论证了为什么传统软件工程会在Agentic AI时代全面失效我们深入剖析了提示词软件危机带来的三大挑战非确定性失控可观测性不足自适应性缺位。我们同时论证了为什么传统软件工程会在Agentic AI时代全面失效最终导致软件工程的在Agentic AI时代的缺位。为此我们提出了一个专为Agentic AI时代设计的、全新的系统性软件工程框架。在本文中我们将详细拆解我们提出的三大核心方法论这三大方法论一对一的解决了三大挑战▴运行时目标精化 (RGR)→ 解决非确定性失控▴可观测认知架构 (OCA)→ 解决可观测性不足▴演化式记忆架构 (EMA)→ 解决自适应性缺位运行时目标精化(RGR)为智能体装上需求导航00核心思想RGR的核心思想是将传统软件工程中需求工程的严谨性从开发设计阶段右移并注入到系统的运行时。这听起来很抽象那就让我们从图1所展示的案例入手进行分析图1在传统软件中图上半部分需求在设计时就被分析师写死了。“订餐”这个目标被分解为“选配送方式—选餐—加购物车—支付”。▴ 当用户在运行时提出新需求比如“请帮我买一个麦当劳的汉堡”系统按预设逻辑执行成功。▴ 但当用户说“请帮我买一张麦当劳的礼品卡”系统就会执行失败。因为它严格遵守设计时的规约MealCatalogService 无法处理“非餐品”。RGR驱动的智能体图下半部分在运行时才开始精化目标。▴ 当用户提出“请帮我买一张麦当劳的礼品卡”时RGR规划引擎并不会盲目去调用选餐服务。▴ 相反它会利用任务知识例如知识库中记载了礼品卡是在“商店”而非“菜单”中来动态地、正确地分解任务“进入商店—选预付卡封面—选金额—支付”。▴ 最终执行器Agent完美地执行该任务。RGR是如何实现这种既灵活又严谨的能力的它主要依赖两个核心支柱的规约。01知识约束的动态目标精化与职责分配知识约束的动态目标精化与职责分配解决的问题正是如何让智能体在运行时既能像ReAct一样灵活又能像GORE目标导向需求工程一样严谨。▴ 在传统GORE中目标精化是在设计时由人完成的。▴ 在ReAct范式中规划是运行时由Agent完成的但它更依赖试错和观察缺乏强约束。RGR融合了二者它将目标精化与职责分配定义成一个能在运行时自动执行但同时受到知识双重约束的过程。这个过程由以下规约定义【规约RGR-Ⅰ.1实现规划引擎】系统应实现一个或多个规划引擎组件。其职责是接收一个高层目标如“买礼品卡”并将其动态精化分解为一组子目标。▴架构模式-单组件该组件可负责从最高层用户意图到最低层原子操作的全栈递归精化。▴架构模式-多组件分层RGR的精化过程是分布式的每个组件负责其特定抽象层级的精化并通过“认知委派”将子目标传递给下一层。【规约RGR-Ⅰ.2使用任务知识约束精化过程】任务知识定义了引擎用来执行逻辑分解的规则、特定领域知识或方法库并支持或等价于KAOS 的核心精化操作如“与/或”分解以确保分解的逻辑完备性。规划引擎的“精化”行为不能是随意的它应受到“任务分解知识”的显式约束。▴AND-Decomposition与分解将一个父目标分解为一组必须全部完成的子目标。▴OR-Decomposition或分解将一个父目标分解为一组可选的子目标。【规约RGR-Ⅰ.3使用“环境知识”指派子目标执行者】环境知识定义了引擎可感知和可操作的范围包括但不限于系统可用的工具、外部 API、以及即时的执行上下文。规划引擎”的输出应遵循 KAOS 的“智能体职责分配”原则每一个新生成的子目标都应依据“环境知识”被指派给一个Agent如特定工具、外部API或其他基于LLM的智能体【规约RGR-Ⅰ.4使用“运行时上下文”动态调整决策】运行时上下文包括此前已执行子目标的状态及其执行结果规划引擎利用此上下文以▴解决动态参数依赖使用先前子目标的执行结果来实例化那些在 [规约 RGR-Ⅰ.2] 中分解产生的依赖这些结果的子目标例如使用“航班搜索”的结果来填充“预订机票”的参数。▴驱动运行时纠错与重新精化当先前子目标的状态为失败时规划引擎必须利用该上下文基于任务知识和环境知识以子目标失败为前提重新尝试精化操作以挽回失败例如执行补偿任务或回溯并继续执行。02运行时需求-期望的识别与转换运行时需求-期望的识别与转换解决了如何确保智能体的执行流程真正完成了用户需求这一根本问题。ReActReflexion等范式主要解决的是智能体如何高效地完成任务的问题而RGR-Ⅱ更关注如何确保智能体能够完成用户的需求。为此RGR-Ⅱ重构了GORE中需求和期望的概念将它们定义为运行时控制流的两种核心状态图2【规约RGR-Ⅱ.1识别运行时需求与运行时期望】规划引擎在精化时必须将每一个子目标分类为以下两种状态之一▴运行时需求一个可被直接指派给系统内智能体去满足的可直接执行或继续AND分解、规约清晰的子目标。▴运行时期望一个非确定性的子目标需要环境用户介入处理。这包括两种情况◦知识/信息缺失 由于任务分解知识或环境知识不足导致该目标既无法直接执行也无法进一步精化例如缺乏必要参数或找不到可执行的Agent。例如买多少钱的礼品卡。◦决策点 在精化后存在多个分支路径而无法自主指派即存在 OR 分解例如图2中多选汉堡的场景。【规约RGR-Ⅱ.2使用用户交互精化运行时期望】规划引擎在识别到运行时期望时应暂停自主执行并激活用户交互严格禁止自主选择一个 OR 分支或臆测缺失的信息。当用户履行了该期望例如做出了选择或提供了信息后系统应基于交互信息更新子目标直至其转变为一个“运行时需求”后才恢复自主执行。【规约RGR-Ⅱ.3为用户交互提供意图支架】用户交互必须作为一个意图支架来设计其职责是为用户提供履行期望所需的必要上下文如图2中的汉堡选项、请求缺失的参数等。可观测认知架构(OCA)告别黑箱构建白箱在上一篇文章中我们指出了当前Agentic AI系统的第二个核心缺陷可观测性不足。由于架构的不透明性与LLM的非确定性相互叠加系统的调试、维护和扩展就变得极其困难。不过这个黑箱问题是怎么产生的呢首先以ReAct、Reflexion为代表的推理范式它们本质上是高层次的行为指导。它们定义了智能体应该如何思考例如“推理-行动-观察”但没有规约智能体该如何在工程上高质量地实现这个思考过程。这种工程规约的真空导致了在实践中架构的碎片化。开发者被迫采用各种特设方法来实现这些行为模式因此产生了大量异质、功能耦合、难以观测的黑箱。为应对这一挑战LangChain、AutoGen等框架提供了一些实现支持并迅速成为业界的事实标准就如同我们在前文中说的那样。它们的贡献是巨大的例如,AutoGen通过结构化的多智能体对话已在一定程度上缓解了黑箱协调问题。然而它们作为事实的实现本身并非一套完备、普适的规范方法论。两者之间的区别在于开发者在采用这些框架时更多的是在采用其特定的技术选型与架构例如你选择使用LangChain的LCEL或是AutoGen的ConversableAgent实现。而不是在遵循一套通用的、可指导软件工程实践的架构原则。我们认为智能体工程亟需一套规范标准来填补这一理论空白。00核心思想为此我们提出OCA(Observable Cognitive Architecture)方法论。OCA的目标就是为RGR、ReAct这类行为范式提供一个健壮的软件工程骨架。它不是一个具体的实现框架而是一套通用的工程蓝图指导我们构建一个可观测、可调试的白箱智能体系统。OCA的规约分为宏观和微观两个层面宏观逻辑—用逻辑分层组织思考在宏观上OCA借鉴了先前的多智能体系统MAS和分层任务网络HTN的思想规约了智能体的认知组织。OCA反对将所有认知规划、记忆、执行混在一个“大泥球”里而是要求将认知过程进行逻辑分层。例如一个高层RGR引擎如同“战略规划部”负责将用户的高层意图分解为大的战略步骤接着通过动态认知委派高层引擎再将这些子任务委派给中层或底层的认知引擎如同“战术执行部”这些底层引擎例如ReAct 范式再负责具体的执行和推理-行动。这种分层与委派的结构使得整个思考链变得清晰、严谨且有据可循。微观实现—用总线实现解耦与观测在微观实现层面OCA借鉴成熟的软件工程原则来确保白箱的可观测性。它首先规定了认知解耦单一职责要求智能体的各个认知组件如Planner、Memory、Executor必须是解耦的。最关键的一点是OCA强制推行状态-控制分离事件驱动架构。它禁止组件之间点对点的混乱调用这正是黑箱的来源并强制所有协调工作通过只两个总线来组织。事件总线(EB)负责控制流所有组件间的通信都必须作为事件发布到EB调试器只需订阅EB就能完整观测到所有决策过程。同时记忆总线(MB)负责状态流所有状态变化都发布到MB允许调试器回溯智能体在每一步的所思所想。通过EB和MB这两大总线OCA将一个不透明的黑箱系统变成了一个完全透明、可调试、可维护的白箱系统。OCA方法论同样由两个核心支柱的规约构成。01基于逻辑分层与认知委派的多智能体架构现代智能体架构缺乏组织多层次任务规划的范式而在符号主义AI时代诞生的HTN则需要人类专家在设计时手动定义所有的分解规则和原子操作。在OCA中我们借鉴HTN的分层思想将其静态的任务分解演变为一个动态的认知委派过程从而定义了在宏观架构层面我们如何将多个 RGR 规划引擎在以分层方式集成为一个可靠的系统。图3所示的案例展示了OCA-Ⅰ所描述的基于“逻辑分层”与“认知委派”架构的多智能体系统。图3【规约OCA-Ⅰ.1采用逻辑分层作为集成原则】系统架构应采用HTN所提倡的分层规划作为宏观集成原则用于在逻辑上组织一个或多个符合 RGR规约的规划组件。系统应根据任务的抽象层级将使用不同任务知识与环境知识的RGR规划引擎在逻辑上分层部署。我们来看图3的案例它直观地展示了单一引擎和分层引擎的巨大差异目标“请帮我买一个麦当劳汉堡包。”▴ 单一引擎如图上部所示一个单一的RGR规划引擎试图一步到位将这个高层目标直接精化为底层的原子操作”如Click(...)。这种端到端的精化是极其困难且脆弱的因为这个引擎需要同时理解用户意图、App逻辑和UI布局而这几乎是不可能的。▴ OCA-I 规约的分层架构如图下部所示OCA-I将认知过程在逻辑上分层RGR 引擎 I (高层/App级)它的任务知识是已安装App列表。它接收高层目标将其分解为App-Level TaskRGR 引擎 II (中层/功能级)它的任务知识是特定App的功能逻辑图。它接收App-Level任务将其分解为App-Functional Goal如“导航到汉堡菜单”RGR 引擎 III (底层/操作级)它的环境知识是当前手机屏幕。它接收功能级目标将其精化为最终的原子操作如Click(‘巨无霸’))。最终这些原子操作被交给原子操作执行器去执行。【规约OCA-Ⅰ.2实现动态认知委派】HTN的分解方法在工程上应被实现为高层RGR引擎的智能体职责分配逻辑即动态认知委派。▴复合任务的认知委派高层引擎的智能体职责分配并非机械式任务分解而是认知过程的委派。它将一个可继续精化的运行时需求及其自主权完整移交给某个拥有合适任务知识与环境知识的RGR引擎由后者启动全新的RGR认知过程。▴委派前置校验委派分解过程是非确定性的。高层RGR 引擎必须首先验证待委派的任务为一个清晰的运行时需求否则分解流程必须在该层级中断例如用户没说选择哪个汉堡则需中断并转而执行 RGR的用户交互流程。▴原子任务的最终委派系统的架构必须定义一个最底层。位于此层级的RGR规划引擎其精化输出的运行时需求必须是原子任务——即一个无需进一步认知委派、可被环境知识直接指派给执行者如工具或 API的最终操作。02基于认知解耦与状态-控制分离的多智能体协作由于以ReAct为代表的现代推理范式缺乏架构约束导致它们在实践中常表现为认知耦合单智能体或不透明的协作与通讯多智能体如图4所示使系统最终沦为不可观测的黑箱。在OCA中我们通过认知解耦与状态-控制分离来填补这一空缺在微观实现层面将多智能体系统构建为一个可观测、可调试的白箱。图4所示的案例展示了OCA-Ⅱ所描述的基于记忆总线MB与事件总线EB实现的多智能体系统。图4【规约OCA-Ⅱ.1实现认知解耦架构】系统架构应采用认知解耦原则。一个智能体不应是原子的黑箱而必须被工程化为一个由多个、职责单一的专职认知组件如规划、决策、反思组件构成的可观测微系统。每个认知组件应能够针对其高度专一的任务进行独立的、轻量化的模型微调。【规约OCA-Ⅱ.2实现显式协调的状态-事件模型】系统必须通过状态-事件混合模型将数据流与控制流彻底分离以实现白箱可观测性。▴显式状态 (数据流)系统应实现一个记忆总线MB作为数据流的唯一真相来源SSoT和可观测的日志。▴显式控制 (控制流)系统应实现一个事件总线EB或等效的确定性调度器作为“控制流”的唯一管理者。组件的激活必须由前序组件发出的特定事件触发而非由数据变化轮询MB触发。【规约OCA-Ⅱ.3遵循确定性协调协议】必须严格禁止认知组件间的直接调用、消息传递或对 MB 的机会主义轮询。所有组件必须遵循确定性协议由 EB 事件触发激活仅从 MB 读取状态将认知结果新状态写入 MB完成后向 EB 发出新事件以触发下一步。演化式记忆架构(EMA)从永恒的新手到演化式专家在前文中我们指出了Agentic AI系统的第三个核心缺陷可演化性缺失。由于缺乏从经验中进行系统性学习的机制现有智能体无法持续优化自己的规划和操作策略。当前我们并不缺乏技术和范式。以CoALA为代表的框架为智能体的心智模型如记忆分类提供了蓝图。动态RAG和持久化反思MPR等技术也为获取知识和转化经验提供了技术基础。然而这一领域面临着与ReAct范式相似的困境缺乏工程规约。我们没有一个统一的、形式化的过程模型来编排这些复杂的记忆活动。这导致关键的记忆巩固环节在工程上仍处于特设状态。正如我们所强调的强大的工具箱如MemOS并不能替代一套完备的方法论。00核心思想为应对这一挑战我们提出了EMA(Evolvable Memory Architecture)方法论。EMA旨在成为连接高阶认知范式与底层技术实现的工程规约。EMA的核心思想如图5所示是借鉴成熟的MAPE-K监控-分析-规划-执行-知识控制循环并将其从单一的自适应循环重构为解耦的执行-演化双环路模型▴规范知识如何存储定义工作记忆与长期记忆的显式分层结构与读写协议。▴规范知识从何而来将实时的战术适应执行循环与异步的战略演化演化循环在工程上彻底分离开。图5EMA方法论由以下两个核心支柱构成。01显式记忆结构与访问控制在CoALA等现代认知蓝图中记忆分层是一个高层的概念模型缺乏形式化规约。在EMA中我们为工作记忆和长期记忆定义了具体的内部结构并规定了读写控制协议从而规范知识如何存储为任务内的执行和任务后的演化提供基础。图5所示的案例展示了EMA-Ⅰ所描述的工作记忆与长期记忆的物理结构与访问方式。【规约EMA-Ⅰ.1: 实现工作记忆】系统应实现一个工作记忆模块 。其核心是一个分层的认知堆栈 用于高保真地记录执行循环中的完整轨迹。在设计时应为工作记忆定义清晰的状态字段例如一个包含 {Plan, Action, Perception, Reflection} 的状态元组。此工作记忆的内容被视为易失的——即无论其是否被持久化存储后续任务均不再直接读写该记忆的原始实例。在任务结束后其完整轨迹全栈将作为演化循环的分析输入。【规约EMA-Ⅰ.2: 实现长期记忆】系统应实现一个长期记忆模块用于持久化存储在演化循环中从经验中抽象和巩固而来的知识。其内部应进一步结构化以区分不同类型的知识至少应包括▴程序性记忆存储关于如何做的技能和策略。在物理上体现为可根据后续任务相似程度检索并复用的操作技巧用于为规划、执行和错误恢复提供任务知识。▴语义记忆存储关于环境是什么的声明性知识。在物理上体现为可根据所处环境检索并复用的环境地图或知识图谱用于为任务拆解与规划提供环境知识。【规约EMA-Ⅰ.3: 实现记忆访问控制】系统应控制并分离不同记忆模块的读写操作。▴工作记忆:写操作 在执行循环期间认知组件如规划器、执行器、感知器可通过在认知堆栈的最上层压入一个新状态来进行高频分层写入。读操作应支持差异化读取如在执行循环中认知组件进行决策时可通过读取栈顶层以获取最新的内容即当前状态或取出指定的若干栈层以获取近期的历史执行情况在任务结束后演化循环应读取全栈内容以获取完整的历史轨迹进行分析。▴长期记忆 :更新操作在执行循环期间应被保护为只读状态仅允许演化循环在任务结束后对其进行更新操作包括新增、改写、删除等操作。查询操作在执行循环期间被规划和决策组件如规划器、行动决策器通过RAG等方式检索并读取以指导其执行行为。这也是 [规约 OCA-Ⅱ.2] 中记忆总线的实现方式之一。02执行循环与演化循环的双环路模型在经典的MAPE-K中控制循环是一个服务于系统自适应如参数调优的单体过程其知识库K被视为静态资源。在EMA中我们对经典的单MAPE-K循环进行了重构将其从外部调优转向内部演化即 K 本身的演化进而将其解耦为一个双环路模型一个服务在执行中快速适应的执行循环另一个则服务积累知识以长期演化的演化循环。EMA规范了知识从而何来为[规约 RGR-Ⅰ.2] 和 [规约 RGR-Ⅰ.4]所依赖的知识提供了保证。图5所示的案例展示了EMA-Ⅱ所描述的执行循环与演化循环的双环路流程。【规约EMA-Ⅱ.1: 实现执行循环】系统应实现一个快速响应的、任务内的MAPE-K 循环即执行循环。此循环的目标是确保任务成功通过运行时反思机制修正由非确定性环境导致的战术偏差通过持续地监控(M) 动作结果、分析(A) 偏差、规划(P) 修正动作、并执行(E) 修正来实现对任务的战术自适应。在此循环中知识库K被高频使用它读/写工作记忆作为其认知脚手架并读取长期记忆作为其决策指导。【规约EMA-Ⅱ.2: 实现演化循环】系统应实现一个慢速的、任务后的post-hocMAPE-K 循环即演化循环。此循环的目标是推动系统演化将工作记忆中的原始经验固化为长期记忆中的可复用能力其定义如下▴M读取完整的任务轨迹工作记忆和当前已积累的长期记忆。▴A对完整轨迹进行高层次反思识别模式化的失败、冗余步骤或更高效的策略。▴P生成一个知识更新计划即规划如何将新学到的经验抽象为程序性记忆和语义记忆。▴E执行规划好的知识更新计划将新知识写入/改写到长期记忆K中。▴K此循环的最终输出目标/更新是长期记忆K本身。作者简介孙家正复旦大学CodeWisdom团队博士生主要研究方向是LLM Agent架构与技术研究特别关注Agentic软件工程与GUI Agent研究牛嘉阳复旦大学CodeWisdom团队硕士生主要研究方向是LLM Agent架构与技术研究特别关注GUI Agent领域李明轩复旦大学CodeWisdom团队硕士生主要研究方向是Mobile GUI Agent 架构与技术特别关注Mobile GUI Agent测试领域审核修改彭鑫复旦大学计算与智能创新学院副院长、教授CodeWisdom团队负责人主要研究方向包括软件智能化开发与运维、人机物融合智能化系统、智能汽车及智能制造基础软件等。排版丨牛嘉阳欢迎关注CodeWisdomCodewisdom平台由复旦大学软件工程实验室运营提供智能化软件开发平台及线上沙龙相关资讯关注可了解更多智能化软件开发的最新消息~