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