我们团队在数简时空平台上构建了一个智能体，目标是让业务人员通过自然语言就能完成数据建库、数据同步、影像发布等操作。最近做了一次操作：对着Agent说一句话，它自动读取三个CSV，识别省、市、县三级关系，生成建表配置，完成3300条数据同步，整个过程不到10分钟。
数简时空智能体自主建表过程与介绍
很多朋友问这套东西是怎么实现的。这篇文章从架构层面，分享我们在Harness、MCP、Skill三个层面的设计思路和协同机制。
一、整体架构：三层协同
先看整体架构（文字描述）：
用户自然语言
↓
┌─────────────────────────────────┐
│ Harness │
│ - Prompt模板 │
│ - 上下文管理 │
│ - 多步推理编排 │
│ - 工具调用决策 │
└─────────────────────────────────┘
↓
┌─────────────────────────────────┐
│ MCP层 │
│ - 标准化工具调用协议 │
│ - 建表接口 / 查重接口 / 审批接口 │
└─────────────────────────────────┘
↓
┌─────────────────────────────────┐
│ Skill层 │
│ - config-create（配置创建） │
│ - data-sync（数据同步） │
│ - image-publish（影像发布） │
└─────────────────────────────────┘
↓
┌─────────────────────────────────┐
│ 平台原生能力 │
│ 元数据 / 权限 / 审计 / 空间 │
└─────────────────────────────────┘核心设计原则：大模型只负责理解和决策，具体执行能力由Skill封装，通过MCP标准化调用，Harness负责编排控制。
二、Skill层：把平台能力封装成"操作手册"
Skill不是简单的函数，而是一份结构化的操作手册。以 config-create 为例：
yaml
skill: config-create
description: 按平台规范创建数据配置项
steps:
- 读取平台配置规范文档
- 检查配置项是否已存在（调用查重接口）
- 根据字段类型生成表结构
- 提交审批
constraints:
- 编码字段必须唯一
- 引用字段必须指向已有配置项
- 审计和安全配置需平台端单独设置这样定义的好处是：大模型不需要知道底层数据库怎么建表，只需要按照Skill的步骤去执行。当平台规范变化时，改Skill文档即可，不用重新训练模型。
演示中，智能体先读取了 config-create 和 data-sync 两份Skill文档，然后才开始执行。这就是Skill在起作用。
三、MCP层：把平台接口标准化
MCP（Model Context Protocol）负责把平台的原生能力标准化，让智能体可以像调用普通函数一样调用。
我们封装了这些接口：
| 接口名 | 作用 |
|---|---|
| config_common_config_select_with_ref | 元数据查重 |
| data_sync_build_mapping | 生成字段映射 |
| data_sync_get_config | 读取同步配置 |
| data_sync_update_config | 更新同步配置 |
| data_sync_run | 执行数据同步 |
每个接口都遵循MCP协议，入参出参标准化。智能体不需要知道接口背后是MySQL还是PostgreSQL，只需要按协议调用即可。
演示中，智能体依次调用了这些接口，最终完成3300条数据同步，0条失败，耗时1.8秒。
四、Harness层：编排与决策
Harness是整套架构的"大脑"。它负责：
-
读取用户意图：从自然语言中提取关键信息（目录路径、配置项名称、数据源类型）
-
选择Skill：判断当前任务需要哪些Skill（建表用config-create，同步数据用data-sync）
-
管理上下文：记住已经执行了哪些步骤，下一步该做什么
-
决策调用：决定什么时候调用MCP接口，什么时候让用户确认
演示中，Harness的编排逻辑大致是这样的：
text
1. 解析用户输入 → 提取目录路径、配置项名称
2. 读取 config-create Skill → 了解建表规范
3. 读取 data-sync Skill → 了解同步规范
4. 调用查重接口 → 确认无冲突
5. 调用 data_sync_build_mapping → 生成字段映射
6. 调用 data_sync_run → 执行同步
7. 输出结果 → 让用户确认如果中间任何一步失败，Harness会捕获错误并决定是重试、跳过还是反馈给用户。
五、协同流程：从一句话到3300条数据
回到那次演示，完整流程如下：
用户输入：
"我在本地有个目录有csv数据，我想根据这些数据做一个行政区划表，新建 test/test_admin_div5 配置项，并导入数据。"
智能体执行：
-
Harness解析意图：提取目录路径、配置项名称、数据源类型
-
Harness读取Skill ：读取
config-create和data-sync文档 -
MCP调用查重 ：
config_common_config_select_with_ref -
Harness分析数据：识别三个CSV的省、市、县三级关系
-
Harness生成映射：确定code、pcode、name、level等字段
-
MCP调用同步 ：
data_sync_build_mapping→data_sync_get_config→data_sync_update_config→data_sync_run -
平台执行同步：3300条数据全部成功，0失败，耗时1.8秒
-
人机确认：提示用户审批
整个过程，智能体没有写一行Python代码，全部通过调用平台已有的Skill和MCP接口完成。
六、与通用Agent的架构差异
为什么通用Agent做不到这件事？
办公类Agent：强项是数据加工，交付静态文件。它没有平台上下文，不知道数据模型规范，也不会调用审批接口。
代码类Agent：强项是生成代码，但代码写完，权限、审计、空间数据关联仍需开发者完成。它交付的是代码工程，不是可运行的系统。
时空智能体：内嵌在平台中，通过Skill和MCP调用平台原生能力，输出的是一份配置清单。确认后，平台自动生成数据库表、接口、表单、权限体系、审计策略及空间数据支持。交付的是可运行的数据通路。
更本质的区别在治理闭环。代码世界有编译器和测试，业务世界没有。谁能查数据、谁发审批、调用怎么留痕、失败怎么回滚，这些都需要平台原生的权限体系和审计策略来保证。时空智能体生成的是一条内建治理规则的动态数据通路。
七、踩坑与经验
坑1：不要试图让大模型直接生成SQL。 我们最初尝试让模型直接写DDL，结果经常出现字段类型不匹配、约束冲突。后来改成让模型生成配置清单，由平台执行，问题解决。
坑2：Skill文档要写得足够细。 一开始Skill文档只写了"创建配置项"，模型不知道要先查重。后来把查重步骤显式写进去，成功率大幅提升。
坑3：人机确认节点不能省。 演示中，智能体在关键节点会停下来让用户确认。这不是能力不足，而是治理需要。政企系统里，自动化不等于无人化。
坑4：要如实反馈边界。 演示中智能体发现建表扩展接口不支持审计配置，它没有强行执行，而是如实说明。这种"知道边界"的行为，比"硬做"更让用户放心。
八、总结
这套架构的核心是：大模型做理解和决策，Skill做能力封装，MCP做标准化调用，Harness做编排控制。 四者协同，才能让智能体从"会聊天"走向"会治理"。
对于正在做政企AI智能体的开发者来说，我的建议是：不要只盯着模型能力，要把更多精力放在Skill定义、MCP接口封装和治理闭环设计上。模型是通用的，但治理底座是你自己的。
希望这篇分享对大家有帮助。