文章目录从运维需求到产品能力OpsArk Agent 的架构设计思路一、先定义任务用户交付的是目标与约束二、组织可复用能力Skill、知识库和任务事实各有职责三、采用阶段规划让计划能够响应现场变化四、设计执行控制把用户参与放在合适的节点五、定义结果与恢复让用户知道完成依据和后续事项六、用用户可感知的行为检验架构从运维需求到产品能力OpsArk Agent 的架构设计思路假设用户提出一个任务“在测试服务器部署这个服务使用指定端口不影响现有业务。”这句话包含部署目标也包含环境、资源和业务约束。产品还需要处理后续变化端口已有监听怎么办用户修改要求怎么办操作超时后怎样知道有没有执行成功从产品经理的视角设计 Agent 架构需要把这些问题转化为能力与交互系统需要知道什么哪些判断可以交给模型哪些操作需要用户参与最终怎样交付结果。本文结合 OpsArk运维智能平台当前实现讨论这些设计选择对应的用户问题与取舍。主线是三个产品目标目标清楚、执行可控、结果可核对。一、先定义任务用户交付的是目标与约束OpsArk运维智能平台是面向运维任务的桌面工作台。用户通过自然语言描述需求系统组织计划连接工具与执行通道再根据实际反馈推进任务。在前面的部署场景中“服务部署完成”只是目标的一部分。指定服务器、端口要求以及保护现有业务也应进入任务的判断范围。产品需要同时管理目标、约束、已确认信息和未完成事项才能解释下一步为什么可以执行。用户中途补充要求时还需要区分整体目标与本轮请求。例如用户要求“先确认端口占用部署暂缓”完成这轮检查后就应交付检查结果并保留尚未完成的部署目标。需求改变后验收范围也需要随之更新。这对应一项架构决策以任务状态组织需求把对话中的要求与后续计划、执行结果关联起来。它的用户价值是让系统持续说明“当前在处理什么、已经完成什么、还剩什么”代价是产品需要维护需求变化与历史事实之间的关系。图 1用户目标通过上下文、规划、执行控制和证据反馈持续推进Skill 与知识检索提供相应支持。图中方框表示功能职责。整体任务链路可以概括为目标与约束 → 上下文与阶段规划 → 执行检查 → 工具或命令执行 → 实际结果与证据 → 完成、继续或调整。二、组织可复用能力Skill、知识库和任务事实各有职责用户每次提出任务都可能需要复用已有方法、相关资料以及当前任务的执行事实。产品需要让这些信息以合适的形式参与规划。信息来源回答的问题对规划的作用Skill这类任务通常怎样处理提供操作流程、阶段建议和验收参考知识库有哪些相关资料与历史经验检索适用片段并保留来源信息任务状态与执行记录这次已经做了什么知道了什么提供当前目标、现场信息、执行结果和待处理事项OpsArk 运维智能平台将这些内容组织进上下文供模型生成阶段计划。所选 Skill 可以提供相应流程信息启用知识检索后相关片段及其引用信息可以进入规划上下文任务记录则保留本次执行的事实。以部署任务为例Skill 可以提供环境检查与部署验收的方法知识库可以提供相关部署经验实际检查结果则说明当前服务器上有什么。历史方法能否适用仍要结合现场判断具体工具权限由执行控制模块管理。这项设计的产品价值在于把方法复用、资料检索和任务连续性分别做清楚。相应成本是维护 Skill 的适用范围、知识资料的版本以及上下文中信息的取舍。加入更多内容并不自动产生更好的计划。知识沉淀也需要设计成独立流程任务记录经预览确认后上传处理形成草稿再经审核发布供后续检索。这样可以管理哪些经验值得复用与此同时也增加了内容整理和维护工作。三、采用阶段规划让计划能够响应现场变化运维任务开始时系统通常还缺少部分现场信息。对产品而言计划需要既能让用户理解接下来的工作又能在获得新信息后调整。OpsArk 运维智能平台采用阶段规划与反馈重规划先提出当前阶段的步骤执行后结合真实结果判断完成、继续或调整。在当前计划从只读检查转入变更时已有观察结果还会参与剩余计划的复核。如果端口检查发现已有监听下一步需要核对绑定地址、资源归属和复用条件。如果新方案涉及改变用户指定的端口或影响已有业务就需要补充相应确认。这里的产品设计重点是说明计划变化的依据。用户应能理解系统发现了什么原计划的哪个前提需要调整以及哪些已经完成的工作仍然有效。阶段规划提供了适应现场的空间同时带来计划维护与额外决策的成本。因此需要控制每一阶段的范围保留有效结果减少缺少新依据的重复检查。新的计划继续受原有目标与授权约束。四、设计执行控制把用户参与放在合适的节点运维操作可能改变外部环境。产品需要明确模型可以提出什么以及系统在什么条件下实际执行。在 OpsArk 运维智能平台中计划中的步骤会接受相应的协议、工具可用性、授权和风险检查按规则决定是否需要审批。通过检查后再由工具执行器或命令执行器经后端通道访问目标环境。从用户体验看计划、风险、命令和校验信息共同服务于操作判断。审批界面的设计目标是让用户理解准备执行的动作及其影响知道这次确认对应什么范围。这里存在明确取舍过多确认会打断任务确认过少又可能让用户难以掌握重要变更。因此需要根据授权范围和操作规则安排介入时机并在目标或方案发生关键变化时重新核对条件。Skill 提供处理方法执行控制模块管理操作权限。这项职责划分让流程知识能够复用同时使实际操作经过统一的执行入口。五、定义结果与恢复让用户知道完成依据和后续事项用户需要的交付包括结果也包括判断结果的依据。命令返回成功是一项执行结果部署目标是否达成还需要对应的验收信息。OpsArk 运维智能平台将需求状态与执行证据关联检查所引用证据的目标归属及适用条件。需求改变或重新激活后完成判断也需要对应当前要求。本轮检查完成与整体部署完成因此可以分别表达。对产品设计而言这要求结果呈现回答三个问题哪些要求已经满足依据是什么还有哪些事项需要处理。这也是判断一次任务交付是否清晰的依据。执行异常时同样需要保持状态清楚。例如操作超时可能发生在远端已执行但回执尚未返回之后。OpsArk 运维智能平台保留结果未知等状态并通过已有记录及支持范围内的只读核对帮助后续处理。这意味着产品有时需要暂停推进向用户说明已知事实和待核实事项。其代价是增加等待与恢复操作但能够为下一步行动提供更明确的依据。停止任务、请求取消和撤销已经发生的变化也需要在交互中分别表达。六、用用户可感知的行为检验架构架构图中的每个模块都应该对应一个可以观察或验证的产品行为。架构决策希望形成的用户体验可以验证的问题任务状态与需求管理目标变化后系统仍能说明当前工作范围本轮请求是否正确影响计划和验收Skill 与知识检索方法和资料在相关任务中被有效使用采用的内容是否适用引用能否核对阶段规划与重规划用户理解下一步及其变化原因新观察是否影响后续方案是否重复已有工作授权与必要审批用户在需要介入时有足够信息判断审批是否清楚是否出现不必要的打断证据、任务结果与恢复完成有依据异常有可理解的后续处理完成结论是否有支持未知状态是否被正确保留这张表也可以用于后续评估。选取一组代表性任务观察目标达成、约束遵守、重复操作、人工接管、耗时与总成本再判断具体架构决策是否值得保留或调整。这些是建议的验证方向不是已经取得的产品成绩。在这个例子中产品经理的架构设计体现在需求到能力的映射用户交付目标与约束Skill 和知识提供方法与参考阶段规划组织工作执行控制落实权限证据与状态支持交付和恢复。模块的职责、相互之间的信息流以及用户在哪些节点参与共同决定了 OpsArk 运维智能平台如何把一句运维需求推进成一个有依据的任务结果。