872 lines
17 KiB
Plaintext
872 lines
17 KiB
Plaintext
# 智能化部署 Agent 技术架构设计说明书
|
|
|
|
## 1. 文档说明
|
|
|
|
### 1.1 文档目的
|
|
|
|
本文档用于在《智能化部署 Agent 方案建议》基础上,进一步细化系统技术架构设计,作为后续研发、联调、评审、实施和试点落地的依据。
|
|
|
|
本文档重点回答以下问题:
|
|
|
|
1. 系统由哪些模块组成。
|
|
2. 云端与本地分别承担什么职责。
|
|
3. 软件 A 如何被接入和封装。
|
|
4. Agent 如何安全地调用部署、验证、日志、监控和第三方接口能力。
|
|
5. 高危动作如何被拦截、确认、审批和审计。
|
|
6. MVP 阶段应实现哪些能力,哪些能力暂缓。
|
|
|
|
### 1.2 适用范围
|
|
|
|
本文档适用于:
|
|
|
|
1. 研发架构设计。
|
|
2. 软件 A 集成设计。
|
|
3. 本地 Agent 设计。
|
|
4. 安全评审。
|
|
5. MVP 实施和试点。
|
|
|
|
### 1.3 设计原则
|
|
|
|
1. 复用软件 A,避免重复建设部署底座。
|
|
2. 所有执行必须受控,禁止模型直接自由执行命令。
|
|
3. 先覆盖标准场景,再扩展复杂场景。
|
|
4. 结论以工具证据为准,不以模型主观推断为准。
|
|
5. 安全、审批、审计与功能同级建设。
|
|
|
|
---
|
|
|
|
## 2. 建设目标
|
|
|
|
## 2.1 业务目标
|
|
|
|
建设一套支持自然语言交互的智能部署与验证 Agent,面向软件交付、实施和运维场景,完成以下工作:
|
|
|
|
1. 触发标准化软件部署,优先支持 Java 应用。
|
|
2. 调用软件 A 完成部署包推送、配置推送、任务执行和状态查询。
|
|
3. 执行日志检查、进程检查、端口检查、健康检查、第三方接口联调验证。
|
|
4. 输出标准化执行报告和结果结论。
|
|
5. 在生产等高风险场景下实现权限、审批、确认和审计。
|
|
|
|
## 2.2 技术目标
|
|
|
|
1. 建立统一的 Agent 编排层。
|
|
2. 建立统一的工具适配层。
|
|
3. 建立云端编排与本地执行分离架构。
|
|
4. 建立统一的任务模型、工具结果模型和审计模型。
|
|
5. 建立面向高风险动作的安全控制机制。
|
|
|
|
## 2.3 MVP 目标
|
|
|
|
MVP 目标是打通一条完整闭环:
|
|
|
|
> 用户自然语言输入 -> Agent 识别任务 -> 策略校验 -> 调用软件 A -> 本地验证 -> 结果汇总 -> 审计留痕
|
|
|
|
---
|
|
|
|
## 3. 总体架构设计
|
|
|
|
## 3.1 架构概览
|
|
|
|
系统采用"云端智能编排 + 本地受控执行 + 软件 A 作为执行底座"的总体架构。
|
|
|
|
### 3.1.1 云端核心职责
|
|
|
|
1. 用户接入与身份认证。
|
|
2. 大模型推理与任务理解。
|
|
3. 任务编排与状态流转。
|
|
4. 风险识别与策略决策。
|
|
5. 审批、审计和结果归档。
|
|
|
|
### 3.1.2 本地核心职责
|
|
|
|
1. 执行云端下发的结构化任务。
|
|
2. 调用软件 A 本地可达能力。
|
|
3. 调用本地验证工具。
|
|
4. 回传结构化结果和执行证据。
|
|
|
|
### 3.1.3 软件 A 的职责
|
|
|
|
1. 作为部署和配置下发的主执行引擎。
|
|
2. 提供部署任务状态查询能力。
|
|
3. 提供日志、监控、配置等基础运维数据能力。
|
|
|
|
## 3.2 架构分层
|
|
|
|
系统分为六层:
|
|
|
|
### 第一层:接入层
|
|
|
|
负责:
|
|
|
|
1. Web 控制台。
|
|
2. 企业 IM 机器人。
|
|
3. OpenAPI 接口。
|
|
|
|
### 第二层:会话与任务层
|
|
|
|
负责:
|
|
|
|
1. 会话管理。
|
|
2. 用户上下文管理。
|
|
3. 原始输入记录。
|
|
4. 任务创建与任务状态管理。
|
|
|
|
### 第三层:Agent 编排层
|
|
|
|
负责:
|
|
|
|
1. 意图识别。
|
|
2. 参数抽取。
|
|
3. 缺参澄清。
|
|
4. 任务规划。
|
|
5. 工具路由。
|
|
6. 结果总结。
|
|
|
|
### 第四层:策略治理层
|
|
|
|
负责:
|
|
|
|
1. 身份与权限校验。
|
|
2. 风险分级。
|
|
3. 二次确认。
|
|
4. 审批流。
|
|
5. 幂等控制。
|
|
6. 执行限流。
|
|
7. 审计日志。
|
|
|
|
### 第五层:工具适配层
|
|
|
|
负责:
|
|
|
|
1. 软件 A 适配器。
|
|
2. 本地验证适配器。
|
|
3. 第三方接口适配器。
|
|
|
|
### 第六层:执行与观测层
|
|
|
|
负责:
|
|
|
|
1. 云端任务调度。
|
|
2. 本地 Agent 执行器。
|
|
3. 日志、指标、Trace、审计采集。
|
|
|
|
---
|
|
|
|
## 4. 核心模块设计
|
|
|
|
## 4.1 接入层
|
|
|
|
### 4.1.1 Web 控制台
|
|
|
|
建议提供以下能力:
|
|
|
|
1. 对话输入。
|
|
2. 任务执行确认。
|
|
3. 审批处理。
|
|
4. 执行报告展示。
|
|
5. 审计查询。
|
|
|
|
### 4.1.2 企业 IM 机器人
|
|
|
|
适合:
|
|
|
|
1. 快速发起查询类任务。
|
|
2. 快速发起测试/预发部署任务。
|
|
3. 审批通知和结果通知。
|
|
|
|
### 4.1.3 OpenAPI
|
|
|
|
用于:
|
|
|
|
1. 第三方系统发起标准任务。
|
|
2. 自动化平台对接。
|
|
3. 审批和工单系统集成。
|
|
|
|
## 4.2 会话与任务层
|
|
|
|
### 4.2.1 会话管理
|
|
|
|
职责:
|
|
|
|
1. 维护用户会话上下文。
|
|
2. 关联最近任务。
|
|
3. 支持多轮澄清。
|
|
|
|
### 4.2.2 任务管理
|
|
|
|
任务状态建议至少包括:
|
|
|
|
1. `CREATED`
|
|
2. `PENDING_CONFIRM`
|
|
3. `PENDING_APPROVAL`
|
|
4. `RUNNING`
|
|
5. `VERIFYING`
|
|
6. `SUCCEEDED`
|
|
7. `FAILED`
|
|
8. `PARTIAL_SUCCEEDED`
|
|
9. `CANCELLED`
|
|
|
|
### 4.2.3 上下文约束
|
|
|
|
会话层不应将全部历史数据无边界提供给模型,建议:
|
|
|
|
1. 只传最近相关任务。
|
|
2. 对日志和工具结果做摘要。
|
|
3. 通过结构化上下文替代长文本拼接。
|
|
|
|
## 4.3 Agent 编排层
|
|
|
|
建议采用状态机方式实现,优先选择 LangGraph 类框架。
|
|
|
|
### 4.3.1 编排节点建议
|
|
|
|
建议包含以下节点:
|
|
|
|
1. `intent_parse`
|
|
2. `slot_extract`
|
|
3. `task_normalize`
|
|
4. `risk_evaluate`
|
|
5. `confirm_required`
|
|
6. `approval_required`
|
|
7. `tool_dispatch`
|
|
8. `verify_dispatch`
|
|
9. `result_summarize`
|
|
10. `audit_persist`
|
|
|
|
### 4.3.2 编排输入
|
|
|
|
输入至少包括:
|
|
|
|
1. 用户信息。
|
|
2. 原始文本。
|
|
3. 会话上下文。
|
|
4. 环境信息。
|
|
5. 应用元数据。
|
|
6. 风险规则。
|
|
|
|
### 4.3.3 编排输出
|
|
|
|
输出至少包括:
|
|
|
|
1. 标准化动作类型。
|
|
2. 结构化参数。
|
|
3. 风险等级。
|
|
4. 任务执行计划。
|
|
5. 工具调用列表。
|
|
6. 最终结论。
|
|
|
|
## 4.4 策略治理层
|
|
|
|
策略治理层必须在模型之外独立实现。
|
|
|
|
### 4.4.1 权限控制
|
|
|
|
建议同时支持:
|
|
|
|
1. RBAC:按角色授权。
|
|
2. ABAC:按环境、应用、租户、动作类型做属性控制。
|
|
|
|
### 4.4.2 风险分级
|
|
|
|
建议按以下维度综合计算:
|
|
|
|
1. 环境级别。
|
|
2. 动作类型。
|
|
3. 是否影响生产流量。
|
|
4. 是否涉及配置变更。
|
|
5. 是否涉及回滚或停机。
|
|
|
|
### 4.4.3 审批流
|
|
|
|
审批流建议支持:
|
|
|
|
1. 单人审批。
|
|
2. 多级审批。
|
|
3. 超时失效。
|
|
4. 审批驳回。
|
|
5. 审批记录审计。
|
|
|
|
### 4.4.4 幂等与并发控制
|
|
|
|
建议实现:
|
|
|
|
1. 任务唯一请求 ID。
|
|
2. 同一应用同一环境互斥执行。
|
|
3. 防止重复部署。
|
|
4. 防止同一审批结果重复使用。
|
|
|
|
## 4.5 工具适配层
|
|
|
|
### 4.5.1 设计目标
|
|
|
|
工具适配层的目标是将不同系统封装成统一可调用能力,避免编排层直接依赖外部系统差异。
|
|
|
|
### 4.5.2 统一工具协议
|
|
|
|
建议每个工具遵循统一协议:
|
|
|
|
输入:
|
|
|
|
1. `tool_name`
|
|
2. `request_id`
|
|
3. `operator`
|
|
4. `target`
|
|
5. `params`
|
|
|
|
输出:
|
|
|
|
1. `success`
|
|
2. `code`
|
|
3. `message`
|
|
4. `data`
|
|
5. `evidence`
|
|
6. `retryable`
|
|
7. `duration_ms`
|
|
8. `timestamp`
|
|
|
|
### 4.5.3 软件 A 适配器
|
|
|
|
建议封装以下能力:
|
|
|
|
1. `deploy_package`
|
|
2. `push_config`
|
|
3. `start_service`
|
|
4. `stop_service`
|
|
5. `restart_service`
|
|
6. `rollback_service`
|
|
7. `query_deploy_task`
|
|
8. `query_logs`
|
|
9. `query_alerts`
|
|
10. `query_metrics`
|
|
|
|
### 4.5.4 本地验证适配器
|
|
|
|
建议封装:
|
|
|
|
1. `check_process`
|
|
2. `check_port`
|
|
3. `http_health_check`
|
|
4. `tcp_probe`
|
|
5. `grep_log`
|
|
6. `jvm_status`
|
|
7. `disk_space_check`
|
|
|
|
### 4.5.5 第三方接口适配器
|
|
|
|
建议封装:
|
|
|
|
1. `invoke_http_api`
|
|
2. `query_cmdb`
|
|
3. `query_config_center`
|
|
4. `create_ticket`
|
|
5. `send_notification`
|
|
|
|
## 4.6 本地 Agent 执行器
|
|
|
|
### 4.6.1 核心职责
|
|
|
|
1. 校验任务签名。
|
|
2. 鉴权与策略匹配。
|
|
3. 执行工具调用。
|
|
4. 采集执行证据。
|
|
5. 回传执行结果。
|
|
|
|
### 4.6.2 执行约束
|
|
|
|
1. 不提供自由 Shell 能力。
|
|
2. 仅允许调用白名单工具。
|
|
3. 每个工具独立参数校验。
|
|
4. 每个工具有超时控制。
|
|
5. 每次执行都写审计日志。
|
|
|
|
---
|
|
|
|
## 5. 云端与本地部署架构
|
|
|
|
## 5.1 部署拓扑
|
|
|
|
建议部署为两部分:
|
|
|
|
### 云端服务
|
|
|
|
1. API 网关。
|
|
2. Agent 编排服务。
|
|
3. 策略引擎服务。
|
|
4. 审批与审计服务。
|
|
5. 元数据服务。
|
|
6. 任务中心。
|
|
7. 模型网关。
|
|
|
|
### 本地服务
|
|
|
|
1. 本地 Agent。
|
|
2. 本地工具插件。
|
|
3. 本地缓存与任务队列。
|
|
4. 本地审计日志模块。
|
|
|
|
## 5.2 通信模式
|
|
|
|
建议采用"云端下发结构化任务,本地回传结构化结果"的方式,避免传输自由文本命令。
|
|
|
|
通信要求:
|
|
|
|
1. 双向 TLS。
|
|
2. 设备身份认证。
|
|
3. 请求签名。
|
|
4. 任务过期时间。
|
|
5. 重放保护。
|
|
|
|
## 5.3 弱网与离线处理
|
|
|
|
建议支持:
|
|
|
|
1. 本地任务重试。
|
|
2. 网络恢复后结果补传。
|
|
3. 审批未完成任务不得离线执行。
|
|
4. 高风险任务必须在线校验策略。
|
|
|
|
---
|
|
|
|
## 6. 软件 A 集成设计
|
|
|
|
## 6.1 集成方式
|
|
|
|
优先级建议如下:
|
|
|
|
1. 首选 API / SDK 集成。
|
|
2. 其次通过网关封装内部接口。
|
|
3. 不建议通过页面自动化方式集成。
|
|
|
|
## 6.2 软件 A 接口能力清单
|
|
|
|
建议与软件 A 对接时确认以下能力:
|
|
|
|
1. 部署任务创建。
|
|
2. 配置推送。
|
|
3. 应用启停。
|
|
4. 回滚能力。
|
|
5. 任务状态查询。
|
|
6. 日志查询。
|
|
7. 告警查询。
|
|
8. 指标查询。
|
|
9. 应用拓扑查询。
|
|
10. 权限透传或操作者记录。
|
|
|
|
## 6.3 软件 A 适配器设计要求
|
|
|
|
1. 对外暴露统一语义接口。
|
|
2. 屏蔽软件 A 错误码差异。
|
|
3. 将软件 A 错误转换为统一错误模型。
|
|
4. 保留软件 A 原始任务 ID 以便追溯。
|
|
|
|
## 6.4 失败处理设计
|
|
|
|
需要区分:
|
|
|
|
1. 调用失败。
|
|
2. 任务创建成功但执行失败。
|
|
3. 软件 A 返回成功但验证失败。
|
|
4. 查询超时或状态不确定。
|
|
|
|
---
|
|
|
|
## 7. 数据模型设计
|
|
|
|
## 7.1 应用元数据模型
|
|
|
|
建议字段:
|
|
|
|
1. `app_code`
|
|
2. `app_name`
|
|
3. `env`
|
|
4. `deploy_type`
|
|
5. `package_type`
|
|
6. `service_start_mode`
|
|
7. `health_check_url`
|
|
8. `log_paths`
|
|
9. `listen_ports`
|
|
10. `dependencies`
|
|
11. `config_templates`
|
|
12. `rollback_policy`
|
|
13. `owner`
|
|
14. `risk_level`
|
|
|
|
## 7.2 任务模型
|
|
|
|
建议字段:
|
|
|
|
1. `task_id`
|
|
2. `session_id`
|
|
3. `tenant_id`
|
|
4. `operator`
|
|
5. `intent_type`
|
|
6. `action_type`
|
|
7. `app_code`
|
|
8. `env`
|
|
9. `version`
|
|
10. `target_nodes`
|
|
11. `risk_level`
|
|
12. `approval_status`
|
|
13. `task_status`
|
|
14. `plan_snapshot`
|
|
15. `result_summary`
|
|
16. `created_at`
|
|
17. `updated_at`
|
|
|
|
## 7.3 工具调用模型
|
|
|
|
建议字段:
|
|
|
|
1. `tool_call_id`
|
|
2. `task_id`
|
|
3. `tool_name`
|
|
4. `request_payload`
|
|
5. `response_payload`
|
|
6. `success`
|
|
7. `duration_ms`
|
|
8. `started_at`
|
|
9. `finished_at`
|
|
|
|
## 7.4 审计模型
|
|
|
|
建议字段:
|
|
|
|
1. `audit_id`
|
|
2. `task_id`
|
|
3. `operator`
|
|
4. `action`
|
|
5. `target`
|
|
6. `risk_level`
|
|
7. `approval_trace`
|
|
8. `tool_trace`
|
|
9. `result`
|
|
10. `timestamp`
|
|
|
|
---
|
|
|
|
## 8. 接口设计建议
|
|
|
|
## 8.1 对话任务接口
|
|
|
|
### 8.1.1 创建任务
|
|
|
|
`POST /api/agent/tasks`
|
|
|
|
请求示例字段:
|
|
|
|
1. `input_text`
|
|
2. `channel`
|
|
3. `session_id`
|
|
4. `tenant_id`
|
|
|
|
返回字段:
|
|
|
|
1. `task_id`
|
|
2. `parsed_intent`
|
|
3. `missing_slots`
|
|
4. `risk_level`
|
|
5. `next_action`
|
|
|
|
### 8.1.2 查询任务状态
|
|
|
|
`GET /api/agent/tasks/{task_id}`
|
|
|
|
返回字段:
|
|
|
|
1. `task_status`
|
|
2. `approval_status`
|
|
3. `tool_calls`
|
|
4. `verification_result`
|
|
5. `summary`
|
|
|
|
## 8.2 审批接口
|
|
|
|
### 8.2.1 提交审批
|
|
|
|
`POST /api/agent/approvals`
|
|
|
|
### 8.2.2 审批通过/驳回
|
|
|
|
`POST /api/agent/approvals/{approval_id}/decision`
|
|
|
|
## 8.3 本地 Agent 回调接口
|
|
|
|
### 8.3.1 拉取任务
|
|
|
|
`POST /api/agent/edge/tasks/pull`
|
|
|
|
### 8.3.2 回传结果
|
|
|
|
`POST /api/agent/edge/tasks/report`
|
|
|
|
## 8.4 软件 A 适配器内部接口
|
|
|
|
建议内部抽象接口:
|
|
|
|
1. `createDeployTask`
|
|
2. `queryDeployTask`
|
|
3. `pushConfig`
|
|
4. `restartService`
|
|
5. `queryLogs`
|
|
6. `queryMetrics`
|
|
|
|
---
|
|
|
|
## 9. 关键流程设计
|
|
|
|
## 9.1 部署流程
|
|
|
|
1. 用户输入部署请求。
|
|
2. Agent 解析意图并抽取参数。
|
|
3. 若缺参则澄清。
|
|
4. 风险引擎计算风险等级。
|
|
5. 若需确认或审批,则进入等待状态。
|
|
6. 调用软件 A 创建部署任务。
|
|
7. 查询部署状态直到完成或超时。
|
|
8. 调用本地验证工具执行校验。
|
|
9. 汇总证据并输出结论。
|
|
10. 写入审计。
|
|
|
|
## 9.2 日志查询流程
|
|
|
|
1. 用户输入日志查询请求。
|
|
2. Agent 识别应用、环境、时间范围和关键字。
|
|
3. 调用软件 A 或本地日志工具查询。
|
|
4. 进行摘要和异常聚合。
|
|
5. 输出结果。
|
|
|
|
## 9.3 第三方接口联调验证流程
|
|
|
|
1. 用户输入联调验证请求。
|
|
2. Agent 路由到第三方接口工具。
|
|
3. 获取响应码、响应体、耗时。
|
|
4. 必要时结合日志和监控交叉验证。
|
|
5. 输出验证结论。
|
|
|
|
## 9.4 生产环境高危操作流程
|
|
|
|
1. 判定为高风险操作。
|
|
2. 执行权限校验。
|
|
3. 执行二次确认。
|
|
4. 发起审批。
|
|
5. 审批通过后再执行。
|
|
6. 执行完成后自动验证。
|
|
7. 写入完整审计链路。
|
|
|
|
---
|
|
|
|
## 10. 安全设计
|
|
|
|
## 10.1 身份认证
|
|
|
|
建议:
|
|
|
|
1. 用户通过统一身份认证系统接入。
|
|
2. 本地 Agent 使用设备证书认证。
|
|
3. 内部服务间使用服务身份认证。
|
|
|
|
## 10.2 权限控制
|
|
|
|
按以下维度控制:
|
|
|
|
1. 用户角色。
|
|
2. 租户。
|
|
3. 应用。
|
|
4. 环境。
|
|
5. 动作类型。
|
|
|
|
## 10.3 敏感数据保护
|
|
|
|
1. Token、密钥、密码不进入模型上下文。
|
|
2. 日志和配置默认脱敏。
|
|
3. 用户展示层默认隐藏敏感字段。
|
|
|
|
## 10.4 Prompt Injection 防护
|
|
|
|
1. 所有日志、接口响应、配置文本视为不可信数据。
|
|
2. 不允许外部文本影响系统策略与审批逻辑。
|
|
3. 模型只能建议,不直接突破策略层。
|
|
|
|
## 10.5 本地执行安全
|
|
|
|
1. 工具白名单。
|
|
2. 参数白名单和格式校验。
|
|
3. 最小系统权限运行。
|
|
4. 限制出站访问范围。
|
|
5. 每个工具独立超时和资源限制。
|
|
|
|
## 10.6 审计要求
|
|
|
|
必须审计:
|
|
|
|
1. 原始输入。
|
|
2. 解析结果。
|
|
3. 风险结果。
|
|
4. 审批结果。
|
|
5. 工具调用。
|
|
6. 验证结果。
|
|
7. 最终结论。
|
|
|
|
---
|
|
|
|
## 11. 非功能设计
|
|
|
|
## 11.1 可用性
|
|
|
|
1. 核心服务支持水平扩展。
|
|
2. 任务执行状态可恢复。
|
|
3. 外部系统短时失败可重试。
|
|
|
|
## 11.2 稳定性
|
|
|
|
1. 每类工具单独超时控制。
|
|
2. 异常分类处理。
|
|
3. 长任务支持轮询与中断。
|
|
|
|
## 11.3 可观测性
|
|
|
|
建议采集:
|
|
|
|
1. 接口日志。
|
|
2. 工具调用日志。
|
|
3. 任务状态流转日志。
|
|
4. Trace。
|
|
5. 指标监控。
|
|
|
|
## 11.4 可扩展性
|
|
|
|
1. 工具插件化。
|
|
2. 应用元数据可配置化。
|
|
3. 策略规则可扩展。
|
|
4. 支持后续增加更多部署类型和中间件类型。
|
|
|
|
---
|
|
|
|
## 12. 技术选型建议
|
|
|
|
## 12.1 编排框架
|
|
|
|
推荐:
|
|
|
|
1. LangGraph 作为核心编排框架。
|
|
|
|
理由:
|
|
|
|
1. 更适合状态机和受控执行流程。
|
|
2. 更适合插入确认、审批和人工干预。
|
|
3. 更适合长期维护和审计追溯。
|
|
|
|
## 12.2 快速原型方案
|
|
|
|
如果需要快速演示,可选:
|
|
|
|
1. Dify 作为前台工作流和对话原型。
|
|
|
|
但长期建议迁移回代码化编排。
|
|
|
|
## 12.3 执行引擎
|
|
|
|
推荐:
|
|
|
|
1. 软件 A 作为主执行引擎。
|
|
2. AWX 或 Rundeck 作为补充能力,不作为主底座。
|
|
|
|
## 12.4 模型接入
|
|
|
|
建议采用模型网关方式,屏蔽底层模型差异,并统一处理:
|
|
|
|
1. Prompt 模板。
|
|
2. 模型选择。
|
|
3. 调用审计。
|
|
4. 敏感信息过滤。
|
|
|
|
---
|
|
|
|
## 13. MVP 范围与边界
|
|
|
|
## 13.1 MVP 纳入范围
|
|
|
|
1. Java 应用标准部署。
|
|
2. 配置推送。
|
|
3. 服务启停/重启。
|
|
4. 日志查询。
|
|
5. 进程/端口/HTTP 健康检查。
|
|
6. 审批和二次确认。
|
|
7. 审计留痕。
|
|
|
|
## 13.2 MVP 暂不纳入
|
|
|
|
1. 任意命令执行。
|
|
2. 复杂自治型多 Agent。
|
|
3. 自动根因分析闭环。
|
|
4. 无人审批的生产自动处置。
|
|
5. 全类型应用和全中间件覆盖。
|
|
|
|
---
|
|
|
|
## 14. 实施建议
|
|
|
|
## 14.1 第一阶段:接口与元数据梳理
|
|
|
|
输出:
|
|
|
|
1. 软件 A 接口清单。
|
|
2. 试点应用元数据模板。
|
|
3. 风险规则表。
|
|
4. 工具协议定义。
|
|
|
|
## 14.2 第二阶段:核心链路开发
|
|
|
|
输出:
|
|
|
|
1. 对话任务接口。
|
|
2. 编排服务。
|
|
3. 软件 A 适配器。
|
|
4. 本地 Agent 基础执行器。
|
|
5. 基础验证插件。
|
|
|
|
## 14.3 第三阶段:治理能力补齐
|
|
|
|
输出:
|
|
|
|
1. 审批接入。
|
|
2. 审计中心。
|
|
3. 任务中心。
|
|
4. 权限模型。
|
|
|
|
## 14.4 第四阶段:试点与优化
|
|
|
|
输出:
|
|
|
|
1. 试点应用上线。
|
|
2. 指标统计。
|
|
3. 问题闭环与优化清单。
|
|
|
|
---
|
|
|
|
## 15. 风险与待确认项
|
|
|
|
以下内容需要尽快确认,否则会影响架构落地:
|
|
|
|
1. 软件 A 当前是否有稳定 API/SDK。
|
|
2. 软件 A 是否支持操作者透传和权限控制。
|
|
3. 本地 Agent 部署环境是 Windows、Linux 还是混合。
|
|
4. 试点应用的部署方式是否统一。
|
|
5. 审批系统和身份系统是否已有标准接口。
|
|
6. 模型是否允许使用云端服务,还是必须私有化。
|
|
|
|
---
|
|
|
|
## 16. 结论
|
|
|
|
推荐将本项目建设为"受控执行型部署 Agent 平台",以软件 A 为执行底座,以 LangGraph 为编排核心,以本地 Agent 为边缘执行节点,以策略治理层保障高危动作安全。
|
|
|
|
从工程落地看,最关键的不是模型能力本身,而是以下四点:
|
|
|
|
1. 软件 A 能否提供稳定可调用接口。
|
|
2. 应用元数据是否完整。
|
|
3. 本地执行是否足够受控。
|
|
4. 审批、权限、审计是否能真正闭环。
|
|
|
|
如果以上四点落实,本项目具备较强的 MVP 落地可行性。
|