煌上煌 Agent 架构

建设统一 Agent 执行平台，保留现有业务系统作为业务数据与流程的权威来源。入口、编排、模型、工具与治理职责明确。

支撑能力的部署边界：以上八项是职责划分，不要求分别部署为八个独立微服务；初期可合并部署，再按负载与维护责任拆分。审批服务优先桥接原 OA / ERP / HR 的权威流程，不默认另建完整审批引擎。Model Gateway、MCP Gateway 保留在主调用链；K8s、数据库、缓存与消息服务属于底层基础设施。

Worker 直接承载各职能 Supervisor 与模块 Graph 的运行；队列是调度通道，不要求每条 Graph 边都跨队列。默认一个运行段由同一 Worker 执行，长等待与本职能内批准的异步工作可拆为持久化工作项。本期不自动跨职能委派，跨职能需求分开办理或使用明确责任方的固定流程。

采用九类职能，系统映射以本版项目范围为准。一个系统可供多个职能使用，每项写操作应明确责任模块、权威来源与业务权限；生产制造、采购与供应链不再对应金蝶 K3，真真老老系统一期全部排除。

依据：HSH Agent系统规划.xlsx，“老系统交接情况”A1:E47，读取于 2026-10-12。本版依据项目要求更新系统映射，未回写原表；无法登录、无数据、下载失败的系统未认定已可接入。

首批建设重点：生产排产子 Agent 与门店 Agent

生产排产：Agent 负责交互与协调，专业求解器负责计算

制造标杆案例：联宝 / 联想与首钢

制造案例来源：联想官网：全栈智能布局与联宝排产；联想官网：高级计划与排程系统；联想官网：生产制造运营智能体（2025-07-01）；首钢官网：热轧生产 AI 智能体（2026-07-20）。均为企业公开披露，不是本项目收益承诺。

门店标杆案例：沃尔玛、星巴克与山姆

门店案例来源：沃尔玛官方：一线 AI 工具（2025-06-24）；星巴克官方：Green Dot Assist 试点（2025-06-10）；星巴克官方：2026 年 AI 应用说明；山姆官方：一线管理 AI（2025-09-10）。这些应用涵盖智能体、AI 助手与 AI 工作流，不均等同于自主执行 Agent。

MCP 接入模式与适配器契约

依据：MCP Authorization、Security Best Practices。网关与准入是项目设计；MCP 不承诺业务审批或跨系统事务。

三类入口共享 Task API、身份、计划和结果。入口承担渠道适配，不各自维护业务执行逻辑。

企业微信以官方开发文档和企业应用权限为准。

POST /api/tasks → 202 + task_id + accepted_status
GET /api/tasks/{id} → 状态、计划、可见结果、最新事件序号
GET /api/tasks/{id}/events → SSE / 分页事件
POST /api/tasks/{id}/decisions → plan_version + decision_id
POST /api/tasks/{id}/cancel → 取消请求，不等于撤销已提交业务

服务器绑定 employee_id / tenant_id / channel / session_id
请求去重 tenant_id + employee_id + client_request_id
决策 / 通知去重 decision_id / channel_message_id / event_id

建议用 Kubernetes（K8s）部署可水平扩展的无状态服务，持久化中间件优先复用企业高可用服务。以下为参考组合，不是采购清单或容量承诺。

任务队列与分布式 Worker

队列机制参考 RabbitMQ Reliability Guide；Outbox、租约与账本为项目可靠性设计。

扩缩容与容量估算

API 按吞吐与资源负载扩缩；Worker 综合队列等待、可运行任务、活跃槽位与下游配额扩缩。模型多为 I/O 等待，只看 CPU 容易低估积压。扩容受模型 RPM / TPM、ERP 限流与数据库连接池约束。

K8s 自定义 / 外部指标需配置对应指标服务；参考 Horizontal Pod Autoscaling。

先形成完整计划，再进入业务执行。统一员工入口通过员工选定的职能 / 模块与后端白名单路由，直接调用各职能 Supervisor；本期不设置员工级总 Supervisor，不进行跨职能自主委派。

为什么采用职能 Supervisor

Supervisor 与其他编排模式的对比

这些模式并非互斥：确定性工作流是业务控制方式，Router、Supervisor、Handoff 等是任务分配 / 协作方式。选择依据是任务复杂度、审批边界、恢复和维护责任，不能仅因“多 Agent”就认定优于固定流程。

模式定义参考 LangChain Multi-agent、LangGraph Workflows and agents。对本项目的选择和取舍为架构分析。

办理流程：员工申请 → 有权限领导接单 → 领导确认并执行 → 员工查看结果

假设可以从 OA、ERP、HR 获取流程定义、审批条件和审批岗位。优先使用原系统审批实例和待办作为权威；Agent 负责生成计划、提交 / 关联申请、展示待办、核验执行条件和汇总结果。领导点击“确认并执行”代表发起受控执行，实际业务由 Worker 通过模块 Graph 和 MCP 完成。

审批规则获取与技术方案

流程与条件的标准化表达可参考 OMG BPMN 2.0.2 和 DMN 1.5。这是可选映射方式，不假设 OA / ERP / HR 能直接导出这些格式，也不要求另建审批引擎；原厂流程能力和 API 需验证。

审批适配器能力（名称为设计示例，需后端注册）：
get_process_definition / evaluate_conditions / list_candidates
create_application / claim_work_item / decide_work_item
get_process_status / get_execution_receipt

申请：application_id / task_id / requester_id / function_scope
计划：plan_version / plan_hash / module_subtasks / steps / dependencies
规则：source_system / definition_id / version / effective_policy / fact_snapshot
实例：external_process_id / current_node / instance_state / state_version
办理：claimant_id / approver_id / executor_id / decision_id / expires_at
委托：task_id + operation_ids + allowed_objects + actions + scope + expiry

所有身份、流程实例归属、handler、凭据和权限字段来自可信后端。
模型不填候选人 ID、不运行审批脚本、不签发执行委托。
审批运行持久化后释放 Worker；事件仅唤醒获准的运行段。

任务流转：先形成完整计划，再进入业务执行

示例：“新增数字零售部，再在该部门新增员工王小煌，最后查询该员工。”以下是正式系统流程说明，仍取决于申请权、执行人权限、数据范围、审批规则与业务条件；姓名 / 部门只是演示示例。

部分办理只在业务策略允许拆分时使用：显示受限和依赖步骤，并生成新的办理子集 / 计划版本，必要时重新审批。整体性流程不得自行裁剪；无实际完成操作不标为成功。

职能父 Graph（目标设计）：
supervisor → dispatch_module → organization_agent / employee_agent
 → collect_module_plan → [继续派发 / policy]
 → [permission_choice（策略允许） / approval_route / execute]
approval_route → persist_wait → interrupt / 结束运行段
审批事件 → 重新入队 → verify_approval → execute → summarize → END

独立模块 Graph：
规划：plan → validate_plan → return_result
执行：execute_tools → return_result

任务：CREATED → QUEUED → PLANNING → PREFLIGHT
 → [WAITING_CLAIM → CLAIMED → WAITING_APPROVAL]
 → READY → QUEUED → RUNNING
 → SUCCEEDED / PARTIAL / FAILED / CANCELLED / NEEDS_MANUAL

审批实例（独立于任务状态）：
PENDING → CLAIMED → [下一审批节点 / APPROVED / REJECTED / RETURNED]
可进入 EXPIRED / REVOKED；多级或会签不能简化为单次 APPROVED

操作：PREPARED / SUBMITTED / SUCCEEDED / SKIPPED / FAILED
NOT_EXECUTED / UNKNOWN / RECONCILING / COMPENSATED / COMPENSATION_FAILED
ROLLED_BACK 仅描述真实本地事务回滚，不替代外部补偿状态。

跨系统失败、版本与恢复

operation_id 与 idempotency_key 稳定，尝试产生新的 attempt_id。跨模块只传经验证对象引用，实际外部 ID 为准；默认执行模块不独立持久化重放。需异步拆分的模块另行设计账本、结果与恢复契约。

框架参考 LangGraph Subgraphs、Persistence；审批桥接、委托、Saga 与账本为本项目拟建设机制。

可信执行依赖有效身份、被授权能力、可访问数据，审批办理还需有效流程与批准证据。条件在每步执行当下成立；申请人、审批人、执行人分别核验。

授权规则与执行身份

• 选择下级权限时补齐上级，选择上级不自动授予下级；新增登录员工默认无业务操作与数据权限。新增申请权 / 审批权也必须显式配置。
• 撤销企业 / 租户职能许可同步撤销相应节点；重新开通不自动恢复。角色、组织或人员有效期变化触发缓存失效，敏感执行同步查询权威授权。
• 申请人与执行人不同，不修改原 task.user_id 伪装任务归属；可信执行上下文显式保存 requester_id、executor_id、service_actor、delegation_ref 与审批证据。
• 执行委托来自后端，限定 task、operation、对象、动作、期限和范围，按最新权力重验；服务凭据只解决系统连接，不替代领导业务权限。
• 原规则要求职责分离时批准与执行必须分人；允许领导合并批准 / 执行的流程才能提供“确认并执行”。没有合法处理人应暂停派单。

全链路检查点

知识、模型与 MCP 的安全边界

• 文档、审批规则文本和工具结果均作为数据：不能修改系统指令、授予权限或发起额外动作；审批条件应先成为受控可验证规则。
• 来源 ACL：文档 / 分片在检索与返回核验，撤权、到期、删除同步；答案附出处。记忆不等于正式批准证据。
• 工具准入：Schema、描述、风险、版本经审核；动态发现只登记，不自动向模型开放写工具或审批决策接口。
• 密钥 / 委托分离：平台、MCP、下游凭据分别管理，短时限定受众；不进入模型或日志，委托不隐含跨业务授权。
• 数据与模型路由：按等级决定字段与模型部署；切换供应商不扩大批准的数据范围。

日志用于排障，执行账本用于恢复，审计解释业务责任。三者关联，但内容、访问角色和保留规则不同。

平台本地审计与外部提交边界

Trace 解释耗时与故障位置，效果评估判断需求是否正确完成。二者共同服务优化与版本发布。

全链路 Trace

HTTP 与消息 headers 传播 OpenTelemetry trace context，task_id 为持久关联键。领导接单、规则匹配、审批恢复、长回调、重投和通知可建立新运行段 Trace，用 Span Link / 任务关联连接，不保持无限长 Span。下游不能传播 Trace 时，适配器记录接口耗时与外部请求 / 单据 ID。

依据：OpenTelemetry Traces。模型 Token、计划版本等为项目扩展属性，按脱敏策略登记。

从评估到优化的闭环

以下按本文中的含义解释，便于业务、技术与管理人员使用同一套表述。