|
缘起
JdySuperClaw 是在简道云平台上构建的一套 AI Agent 工具集。
缘起于2026年5月份为简道云官方「AI 功能打卡营」录制课程。课程中接触到智能助手 Pro 的 AI Agent 节点，它具备自主理解目标、规划决策、执行行动的能力，可将插件做为工具来调用。4月初，官方发布的 OpenClaw 相关 Skill 时已做过相关的测试及能力拓展，那是否有可能把所有能力都基于简道云的生态闭环式的构建起来呢？这样使用者就不必要再去依赖外部工具或服务。
课程录制结束后，项目正式启动，中间经历过多次版本迭代及技术性调整，目前整体逻辑框架及可实现的功能已趋向稳定，现将实践中的关键决策进行了初步整理，特此分享。
项目边界与约束
OpenClaw、Hammers、WorkBuddy 等工具通过技能包扩展了 AI Agent 操作 SaaS 数据的能力；Codex、Claude 等则通过代码生成或工具调用与业务系统交互。简道云智能助手 Pro 也提供了相应的 AI 节点机制，官方技能包目前聚焦于数据查询场景，这一设计边界很可能是出于数据安全层面的考量：在开放更多操作能力之前，先确保查询层面的权限和审计机制足够稳健。
我们的实践目标是在同一安全边界内做拓展：查询、录入、修改、删除、审批、汇总，全部在简道云内闭环完成，数据不出平台，不引入外部依赖。
这个约束决定了所有技术决策的基调：在围墙内解决问题，而不是拆掉围墙。
两个原则从始至终没有动摇：
数据不出简道云。
权限隔离。 AI 节点只负责"理解需求、选择工具"，不接触平台密钥，不参与权限判断。即便 AI 发出了越权指令，在请求到达 API 之前就会被拦截。
三层架构
系统基于简道云现有的三部分能力构建：
`入口表单（自然语言）→ 智能助手 Pro（AI 节点 → 插件运行时）→ 结果
`
-
自建插件（Python 3.10）：封装 60+ 简道云 OpenAPI v5 操作，持有 API 密钥，实际执行数据请求
-
AI 节点（System Prompt）：角色提示词驱动 AI 的行为——它只负责"理解用户想干什么、选哪个工具"，看不到也接触不到平台密钥
-
通用参数（Global Template）：权限控制（7 类操作开关）、凭证管理、提示词注入。所有权限判断在请求到达 API 前完成
插件持有密钥，AI 只做决策，通用参数做闸门。即便 AI 发出了不在权限范围内的指令，在插件层就会被拦截，不会到达简道云 API。
架构看起来完整，在初期测试时整体流畅无问题，但当压力测试来了，面对大量级数据时，第一步就崩了。
于是有了下面这六次决策。
六次关键决策
决策一：提示词放在哪
最初提示词直接写在智能助手节点的系统提示词字段里。自己用没问题，但别人要用这个能力，得把整个模板应用搬过去——配置繁琐，几乎不可分发。
解法：将提示词迁移到插件的通用参数中。用户在插件配置界面填入提示词，AI 节点在运行时通过 agentConf 读取。插件安装即用，提示词与代码分离，改提示词不用重新部署。
这个决策打开了一个重要的架构方向：代码与提示词分离。后面所有角色提示词都沿用了这个模式。
决策二：代码体积超过平台上限
简道云限制单个 .py 文件不超过 128KB。数据中枢.py 封装了 60+ API 操作、路由、权限、日志——还有一份 30KB 的场景字典（GUIDE_DATA）。加起来 153KB。
超了。
两个方向都试了：把操作指令从代码移回提示词（提示词太大），保持现状（超限无法上线）。都不行。
最终解法：把 GUIDE_DATA 从 Python 代码中彻底剥离，以紧凑的 Markdown 表格格式合并到角色提示词里。数据中枢.py 从 153KB 降到了 104KB，余量 24KB。同时删除了元指令方法——这些信息已经直接内置到提示词里，AI 不再需要通过 API 去"学习"工具有哪些。
这个决策确定了一个原则：静态知识（操作说明、参数文档）放提示词，动态逻辑（API 调用、数据处理）放代码。
决策三：节点拆分——先解决一部分问题
数据量的问题开始暴露。
最初设计是一个 AI 节点包揽全部：数据查询、提取、报告编辑，都在一个节点里完成。这要求一个节点同时处理"拿数据"和"写报告"两件不同性质的事，上下文压力翻倍。
解法：拆成两个节点。
坦率地说，拆完很清楚：第二个节点大概率还是会被撑爆。上下文窗口没变，数据量没变，只是把问题从"在一个节点里爆"变成了"在第二个节点里爆"。
但这样做有一个实际收益：节点一在大多数情况下可以稳定运行。 先保证数据能拿到、能存下来，再解决分析和报告的问题。即使第二步暂时走不通，第一步的成果没有白费——数据已经在日志里了。
"先解决一部分问题，再解决剩下的问题"——这个思路贯穿了后续所有的技术决策。
决策四：附件存储 + 格式压缩
节点拆开后，节点一的首要任务是保证数据能安全落地。
原始逻辑是：插件查数据 → JSON 返回给 AI。大量级 JSON 数据直接塞进上下文，必爆。改为以 .md 附件形式上传到日志表单的附件字段，AI 只拿文件链接。附件不占用 AI 上下文，前端渲染也不卡。
同时把原始 JSON 转为 Markdown 表格，节省 40~60% 的体积。还优化了附件结构：appId / entryId 每行重复，移到文件头部只标注一次；_id 完整 24 位显示没必要，只保留后 10 位。
文件预检也是在这个阶段加入的：要求 AI 提取附件前先检查大小，超过阈值直接终止。
但阈值设多少才合适？从 100KB 一路降到 10KB——一条普通文本记录的体量——仍然会在某些场景下出问题。
这个数字让思路发生了转折：如果把阈值压到 10KB 才能安全通过，那这个工具实际上已经没什么用了。 问题不在阈值设多少，而在于"让 AI 直接处理原始数据"这个思路本身就是错的。
前三轮尝试（节点拆分、附件存储、格式压缩）都在"怎么把数据传给 AI"这个层面打转。它们没有解决问题，只是延缓了问题的发生。方向错了。
决策五：在插件内完成数据聚合（核心突破）
问题的本质：AI 的上下文窗口有物理上限，你不可能把一个万行级的数据集完整塞进去让它处理。
简道云插件运行环境提供了 pandas。这意味着一件事：可以在插件运行时内完成数据聚合，只把汇总结果返回给 AI。
`# 在插件内部完成聚合
raw_data = fetch_all_pages(app_id, entry_id) # 分页拉取全量数据
df = DataFrame(raw_data)
result = df.groupby(group_by).agg(metrics) # pandas 聚合
return result.to_dict() # 只返回聚合结果（几十行）
`
实测效果：
| 场景 |
原始数据 |
聚合结果 |
压缩比 |
| 6 月数据按天分组 |
232 条 |
15 行 |
15x |
| 全量数据按月分组 |
838 条 |
3 行 |
279x |
这个决策把"数据预处理"的责任从 AI 上下文移到了插件运行时。节点一和节点二拿到的都是经过压缩的数据，上下文压力从源头被化解。
聚合上线第一天就遇到一个问题：datetime 字段精确到秒，按原始值分组几乎等于按每条记录分组。838 条数据产生了 807 个分组，聚合了个寂寞。
优化：自动检测字段类型，对 datetime 维度默认按 day 截断。优化后同数据集从 807 组降为 76 组（按天），按月仅 3 组。
这个方案也有边界：数据量再大一个数量级时，插件内部的翻页拉取和聚合操作可能无法在平台 60 秒超时限制内完成——这是当前架构下仍待解决的问题。
决策六：语义理解代替关键词匹配
有了聚合工具，AI 得知道什么时候用它。
最初的规则是关键词匹配："整理/归档/分析"→聚合，"查一下/找一下"→明细。但马上发现不对——"查一下6月份销售情况"是汇总需求，"查一下2024-001号订单详情"是明细需求，关键词完全一样。
解法：AI 接到查询任务后，第一步不是选工具，而是分析用户意图——"看全貌"还是"查细节"。语义判断取代关键词匹配，同时确立"聚合优先"为最高优先级行为约束。
这个决策与决策五形成闭环：语义理解告诉 AI 什么时候该聚合，数据聚合让 AI 有能力处理大数据。两者缺一不可。
一些额外的尝试
前端微应用。 简道云的前端函数（Applet）通常用于简单交互弹窗。在这个项目里做到了另一个量级：应用简介、在线 Markdown 渲染器、帮助文档——在弹窗内独立完成页面渲染，不跳转、不嵌入，在简道云前端框架内完成完整的品牌展示和文档阅读体验。
文本直接写入附件。 执行日志需要存数据供追溯，但文本字段渲染会卡死。常规路径是生成文件→上传外部存储→获取链接→写入附件。试了一条更直接的路：在内存中构造文件对象，通过插件 API 直接写入附件字段。这个"文本即附件"的思路在后续的聚合日志、报告输出里被反复复用，整个执行链路不再依赖外部存储。
现状与局限
当前能力：数据查询与操作（含字段瘦身、批量获取）、流程审批（通过、驳回、转交、加签）、组织与角色管理、聚合分析（按任意维度和指标分组汇总）、报告生成。
已知局限：聚合损失维度精度，需要 AI 判断合适的粒度；全量分页查询耗时 10~30 秒，受平台 60 秒超时限制；不支持跨表单聚合；所有数据闭环仍在简道云内，不依赖外部存储。
在悟帆中的延伸验证
JdySuperClaw 的核心逻辑也以 skill 形式接入了悟帆——简道云官方推出的 AI Agent 引擎平台——进行了验证。在 Agent 环境中，同一套 API 封装和聚合逻辑获得了更完善的工具调用支持和更体系化的 skill 管理能力，可拓展性明显强于原生插件环境。
这进一步验证了分层架构的思路不依赖于特定运行环境：无论是受限的插件沙箱，还是更完善的 Agent 平台，把数据预处理留在代码层、把决策留给 AI 这个边界划分都成立。
总结
回顾整个过程，最核心的认知是：AI Agent 的能力上限不取决于模型本身，而取决于生态能为它提供多厚的"支撑层"。
在零代码平台上构建 AI 能力，每个限制都对应一个技术决策。但比单个决策更重要的是决策背后的模式识别——当你发现自己在同一个层面反复优化却收效递减时，很可能需要向上跃迁一个抽象层级。
| 问题 |
决策 |
| 提示词不可分发 |
迁移到插件通用参数，代码与提示词分离 |
| .py 文件 128KB 上限 |
静态知识放提示词，动态逻辑放代码 |
| 单节点上下文压力大 |
拆为数据操作 + 报告编辑两个节点 |
| 大文件撑爆上下文 |
附件存储 + Markdown 格式压缩 |
| AI 上下文窗口有限 |
在插件层用 pandas 完成数据聚合 |
| AI 选错工具 |
语义判断 + 聚合优先原则 |
前三次决策（节点拆分、附件存储、格式压缩）在同一个层面打转：怎么把数据传给 AI。直到第四次认知跃迁——与其让 AI 处理大数据，不如让大数据在到达 AI 之前变小——问题才真正被解决。
这套模式不局限于简道云。项目积累的 API 封装、聚合逻辑、安全策略可以打包为技能包部署到其他 Agent 平台，其核心思路——在受限环境中通过分层架构来化解 AI 的能力瓶颈——具有跨平台的可迁移性。
回到开头那个场景：那条在第一步就崩溃了的流程，现在能跑通了。超量级数据不再涌入 AI 的上下文窗口，而是在插件内部被压缩、聚合、结构化——AI 拿到的是它能够处理的体量。
在"AI 能做什么"和"插件能做什么"之间，边界到底在哪？
答案是：边界不在技术能力，而在设计选择与生态支撑——你选择把什么责任交给 AI、什么责任留在传统代码层，以及平台能为你提供多厚的支撑层。这两者，共同决定了整个系统的上限。
本内容由 MS-Super-Write-Agent 基于开发资料联合编辑
■ 更多内容
导航：云函数&前端事件&自建插件 内容集
汇总：论坛中发表过的所有帖子
承接简道云技术咨询与应用定制
承接月度技术支持服务
更多沟通交流可添加微信：zmlnow
添加时请备注：简道云
| 
