一 、建设目标与应用边界

建立可复用的通用型 AI 智能体基础架构，将任务理解、资料检索、规则判断、方案生成、工具执行、效果核验和反馈迭代连接为同一工作闭环。以物质链、文化链、精神链三链同时态协同为核心，使每项任务形成可追溯的事实依据、可执行的行为规则和可检验的整体成果。

二、三链协同总体架构

三链作为同一任务的三个并行观察与处理维度，通过统一任务标识、事件记录与状态快照相互关联；每轮执行均同步更新事实、规则和效果，不采用单向“底层—中层—顶层”关系。

2.1 三链共同的任务对象

统一对象 task_id 关联 demand_id 、evidence_id 、rule_version 、plan_id 、execution_id 、

evaluation_id 、feedback_id 。所有记录包含 tenant_id 、owner_id 、created_at 、source_ref 、status和 version ；敏感字段按项目权限隔离。

2.2 三链交互闭环

需求进入 → 三链并行建模 → 证据与规则交叉校验 → 生成候选方案 → 综合评议与决策 → 授权执行 → 记录真实结果 → 更新事实、规则和效果评价 → 启动下一轮任务。

三、系统逻辑组件

四、智能体角色与运行机制

4.1 协同与共识

总控智能体并行请求物质链、文化链和精神链分析；各智能体以结构化 JSON 返回结论、证据引用、分

歧 、置信度与待补资料。对事实冲突优先回查数据来源；对规则冲突调用生效规则与责任人裁决；对目标冲突展示候选方案及影响 ，由授权责任人确定执行路径 。

4.2 停止与升级条件

同一子任务至多进行 3 轮自动评议；连续两轮无新增证据或实质修正时停止循环。证据不足 、规则冲突未解决或高影响动作未经审批时进入待处理状态，保留完整上下文供人工接续 。

五、三链数据、知识及规则设计

5.1 物质链：历史事实与存证

数据接入   支持 PDF 、DOCX 、网页、表格 、业务数据库与事件流；入库时记录来源、作者/责任人、时间、版本、授权范围及文件摘要 。

知识索引   以项目或租户分区 ，建立关键词索引与向量索引 ；检索结果携带原文段落 、页码/记录号 、有效期和访问权限。

历史权重   可按业务配置时间衰减 W_h=exp[-ln(2)×Δt/h] ；适用于时效性强的数据。长期有效制度、历史档案及关键先例由规则指定不衰减 。

证据链   文件哈希 、版本号与不可覆盖事件日志绑定。需要跨机构共享时可选第三方存证或区块链锚

定；一般部署采用数据库 、对象存储及签名审计即可。

5.2 文化链：规则与行动

规则结构   每条规则至少包含 rule_id 、scope 、condition 、action 、priority 、effective_at 、 expires_at 、owner 、approval_level 和 version 。

规则执行   先鉴权，再按生效期 、适用范围 、优先级进行匹配 ；冲突时记录命中规则及冲突原因 ，不通过文本生成模型直接修改生产规则。

规则治理   修改走“提出变更—影响评估—责任人审核—测试—发布—回滚”流程；可将原文中的 DAO 治理思想映射为多角色提案与审议机制。

5.3 精神链：整体效果与反馈

评价对象   以真实任务结果为对象，分别记录目标完成、事实可溯源、规则符合、相关方反馈、资源效率和长期影响 。

评价输出   形成 evaluation_id 、各维度证据、争议项、人工结论及修正提案；不将自动生成的评价值当作对人的精神价值的客观测量。

Token 机制   运行 Token 表示模型输入与输出的计量单位；若采用原理论中的“精神穿透力 Token” ，单独设置业务影响事件指标impact_event ，不与模型计费 Token 或可交易资产混同。

六、标准执行工作流

七、接口与数据协议

7.1 服务接口

7.2 任务请求与输出示例

请求 ：{"tenant_id":"org-a","task_type":"document_analysis","goal":"依据指定资料形成执行方案","inputs":[{"type":"file","ref":"doc-001"}],"constraints":{"language":"zh-

CN","approval_mode":"manual_for_write"}}

输出 ：{"task_id":"task-001","status":"validated","chain_state":{"material":"ev-001","cultural":"rule- v3","spiritual":"eval-001"},"output_ref":"result-001","citations":["doc-001:p2"],"version":"1.0"}

7.3 工具调用约定

每个工具登记 tool_id、输入 JSON Schema、输出 JSON Schema 、允许调用角色、权限范围 、超时、重试次数及副作用等级 。写入动作要求 idempotency_key ；任何失败返回 error_code 、message 、retryable与 trace_id ，不以自然语言“ 已完成”替代工具回执。

八、模型、知识及部署配置

8.1 最小可运行部署组合

前端工作台 + API 服务 + 任务编排服务 + 3 个三链分析角色 + 执行/验收角色 + 模型服务 + 关系数据库 + 对象存储 + 检索引擎 + 工具网关 + 监控日志。首期优先上线“资料分析—方案生成—人工确认—交付归档” 闭环，再扩展业务系统写入和复杂多智能体流程。

九、反馈迭代与质量验收

9.1 否定之否定闭环

以“ 当前方案—现实执行结果—差异分析—修正方案—再执行”形成版本化迭代。每轮保留原始依据、候选方案、选择原因 、执行回执和实际效果；知识变化更新索引 ，规则变化提交审批，提示词或模型变化须先通过回归评测 。

十、实施阶段与交付清单

10.1 项目可配置交付模板

每个行业项目分别建立 ：场景配置表（目标、用户、触发条件、完成标准） 、物质链资料清单（来源与更新频率） 、文化链规则清单（权限及生效期） 、精神链评价表（效果与反馈） 、工具白名单、角色提示

词 、测试用例和验收记录。由此复用同一架构，按项目替换知识、规则、工具及评价配置 。