设计理念
TEVER Cortex 的方法论——两层架构，十个概念，从描述世界到执行工作。
TEVER 的来历
太微（Tài Wēi），源自中国古代星官名——太微垣， 三垣之一，古人视为天庭的行政中枢。 取名"太微"，寓意平台是数字世界的行政中枢—— 信息汇聚于此、规则在此匹配、任务在此分派、结果在此记录。
TEVER 这五个字母也是平台描述层的核心—— Type / Entity / View / Event / Rule。它们定义了平台如何描述和理解世界。
而 Cortex（皮层）则代表平台另一面——执行层： Capability / Orchestration / Runner / Testify + Execute。 它负责把描述转化为行动。
两层架构
TEVER Cortex 的方法论建立在一个简单的二分之上：一部分负责"描述世界"， 一部分负责"执行工作"。两者通过 Rule 连接。
| 层次 | 职责 | 五个概念 | 一句话 |
|---|---|---|---|
| 执行层 CORTEX | 执行工作 | Capability · Orchestration · Runner · Testify · Execute | 谁、做什么、按什么顺序、怎么检查 |
| 描述层 TEVER | 描述世界 | Type · Entity · View · Event · Rule | 有什么、发生了什么、怎么呈现、何时触发 |
描述层 TEVER — 平台的语言
描述层定义世界中有哪些事物、发生什么变化、如何呈现。 它是平台和所有执行层概念的统一语言。
| 概念 | 回答的问题 | 含义 |
|---|---|---|
| Type | 有哪些类型？ | 定义事物类别——什么是"资讯"、什么是"报告"、什么是"任务"。Type 定义了数据结构和校验规则，确保信息在系统中传递时不走样 |
| Entity | 具体是什么？ | Type 的实例——一篇具体的资讯、一份具体的报告、一个具体的客户。Entity 是信息在平台中流转的载体。每个 Entity 属于明确的 Type，可被校验、追溯 |
| View | 怎么看？ | 同一 Entity 面向不同角色的呈现方式。客户看分析结论，审计者看操作轨迹，知识图谱看结构化提取结果。不同视角，同一实体 |
| Event | 发生了什么？ | 一切变化的记录。Runner 认领了任务、Skill 产出了 Entity、Testify 通过了校验——每一步都是 Event。Event 按时间串联，形成完整的因果链条 |
| Rule | 何时触发什么？ | 两层之间的桥梁。Rule 监听 Event，当条件满足时触发执行层的操作——启动 Workflow、调度 Runner、调用 Skill。Rule 声明的是"意愿"（该做什么），不指定"怎么做" |
执行层 CORTEX — 平台的双手
执行层负责实际完成工作。被 Rule 触发后，执行层接管： 谁来做、做什么、按什么顺序、做得怎么样。
| 概念 | 回答的问题 | 含义 |
|---|---|---|
| Capability | 能做什么？ | 平台的原子执行能力——采集资讯、调用模型、发布内容、推送消息、提取实体。每个 Capability（即 Skill）声明自己的 Type 接口：消费什么 Entity、产出什么 Entity。加能力 = 声明一个新 Capability |
| Orchestration | 按什么顺序做？ | 编排多个 Capability 的执行顺序——哪些可以并行、哪些必须串行、谁依赖谁的输出。从简单的顺序链到复杂的条件分支，都由 Orchestration（即 Workflow）定义。改流程改编排，不改造 Capability |
| Runner | 谁来做？ | 任务的执行主体（即 Agent）。Runner 认领任务、调用 Capability、回报结果。平台统一协议——注册、认领、执行、回报——Runner 内部如何实现则不受约束。内部 Runner 由平台直接管理，外部 Runner 独立运行 |
| Testify | 做得对不对？ | 对 Capability 的输出进行多维度验证——格式是否符合 Type 声明？数据是否在合理范围？内容逻辑是否自洽？Testify（即 Evaluator）不通过时自动反馈修正，多次失败走容错路径，保证链条不中断 |
| Execute | 怎么执行？ | 执行层作为整体的运作模式。Execute 代表执行层的核心理念：Capability 被 Runner 调用，按 Orchestration 定义的顺序推进，每一步被 Testify 验证，整个过程被 Event 记录 |
两层协作：一个完整的工作流
以"每日行业报告自动生成"为例，看两层如何配合运转：
描述层 Rule 触发 → 执行层启动
定时 Rule 在每天 7:00 触发。Rule 声明了"到这个时间就启动日报生成工作流"。执行层运转
Orchestration 启动采集→分析→评估→发布→推送的顺序链。Runner（采集 Agent）调用 Capability（采集 Skill）， 产出 Entity（资讯）。Orchestration 继续推进： 分析 Runner → 分析 Capability → 报告 Entity →Testify 校验报告质量 → 发布 Runner 调用发布 Capability → 推送 Runner 调用推送 Capability。描述层同步记录
每一步执行都生成 Event（谁、何时、对什么 Entity、做了什么、结果如何）。 报告 Entity 通过 View 双轨沉淀——原文归档为非结构化文档，关键实体提取到知识图谱。可审计
三周后客户问"这个结论怎么得出的？"→ 沿 Event 链回溯： 推送 Event → 发布 Event → Testify 通过 → 分析 Event → 采集 Event → 原始资讯 Entity。 每一步的 Type 约束确保数据完整、Runner 身份明确、Capability 操作清晰。View 双轨沉淀与数字顾问
执行层产生的报告、分析、数据——如果只是推送出去就结束，每次都是"一次性劳动"。 TEVER Cortex 的做法是让每一次执行成果都沉淀为知识资产。
- 非结构化 View——完整报告原文归档到知识库，按时间和主题索引，供人类阅读检索
- 结构化 View——从报告中提取关键 Entity 和关系，写入知识图谱，供机器精准查询和推理
两轨知识共同支撑数字顾问。客户提问时，数字顾问从结构化 View 中定位精确数据， 从非结构化 View 中获取上下文背景，生成既有数据支撑又有完整语境的回答。
从 Rule 触发 → 执行层运转 → Entity 产出 → View 双轨沉淀 → 数字顾问——每一次自动化工作流都在为顾问"备课"。
设计原则
- 描述与执行分离
TEVER 描述世界，CORTEX 执行工作。改描述不影响执行，改执行不破坏描述。 - Rule 桥接两层，确定性优先
Rule 是描述层中唯一能触发执行层动作的概念。用声明式 Rule 而非硬编码控制流程。 - Event 记录一切
执行层的每一步操作都是描述层的一个 Event。完整的因果链意味着可追溯、可验证、可审计。 - Type 约束接口，Entity 承载数据
Capability 之间的交互以 Type 为契约。格式错误在上游被 Type 校验拦截，不污染下游。 - 多租户原生，十概念皆带边界
从描述层的 Entity 到执行层的 Runner，每个概念都带有租户边界。隔离是基础设施，不是事后补救。 - 数据不出域
支持多租户共享平台和企业独立部署。客户数据始终在客户掌控范围内。