AI 能帮我们搭页面、写接口、补脚本。原型做出来以后工程问题才开始集中出现多个部门怎么共用工具拿谁的权限执行检索到的资料能不能给当前用户看一个脚本卡住会不会拖慢整个服务这些问题也是我们在联犀项目中组织 AI、SaaS 与 IoT 能力时需要处理的内容。下面结合已有界面与架构设计讨论权限、知识、工具和运行时怎样接到一起。截图保留当时版本的实际界面场景设计与已展示的操作分别说明。原型能跑离多人使用还有多远单人助手里使用者通常也是配置工具、管理资料的人。进入企业系统以后同一个问题可能需要经过组织、项目、角色和业务流程的共同约束。要核对的问题单人使用时多人业务系统中身份当前使用者当前用户、组织、项目与角色资料范围使用者提供的资料按权限筛选后的文档和业务数据工具调用使用者配置的工具工具权限与业务接口鉴权共同约束执行失败影响当前任务需要限制对其他用户和服务的影响结果验收使用者判断需要来源、状态、日志与业务核对区别不在于聊天窗口放在哪里而在于一次回答、一次工具调用能否沿着这些边界走完。可以先选一个小场景验证用户查询某个项目的设备运行情况。系统先确认用户身份和项目范围工具再读取获准的数据返回结果应包含查询时间、设备范围、统计口径和异常情况。模型把结果组织成文字或图表并不改变原始数据的归属。权限留在业务服务里AI 需要知道自己正在服务谁、处理哪个项目但提示词里的身份说明不能代替服务端鉴权。在已有 SaaS、IoT 系统中接入 AI可以先复用用户、角色、项目和设备的权限关系。一次调用需要核对四件事身份从哪里来由登录会话或受控的服务身份提供不能让模型自行填写身份后取得权限。对象是否属于当前范围设备、文档、报表是否在该用户获准访问的组织与项目中。动作是否获准允许读取状态不代表允许控制设备或修改业务配置。结果是否仍需过滤工具返回的数据、检索片段和引用来源也要符合当前用户的数据范围。例如用户让 AI“看看这个项目有哪些设备”工具应在业务接口已经约束的项目范围内查询。即便模型生成了另一个项目的编号服务端也应拒绝越权请求而不是相信模型已经检查过。这层约束适用于网页、CLI、本地助手等不同入口。入口可以不同业务接口的权限判断不能因此省略。知识检索和长期记忆分开组织企业 AI 往往同时接触知识库、会话记录、用户偏好和业务对象。它们更新的频率不同来源与可信程度也不同不宜全部当成一段长期提示词。原文中的 Hermes 记忆管理界面展示了 L1、L2 记忆层级和 Dream 运行入口。它用于说明近期交互与长期记忆可以分别组织界面本身不代表每条记忆都已经核实。设计这类链路时至少要考虑记忆的来源、更新与失效用户后来纠正的信息如何覆盖旧记录项目结束后相关上下文是否仍应进入新会话权限发生变化后旧记忆还能不能被装配进回答知识库则需要保留文档结构与来源。下面是联犀知识库工作台的实际界面左侧是文档目录中间是正文右侧是 AI 助手。阅读和提问放在同一工作区便于对照资料核验。验收时不要只问“回答通不通顺”。还应检查引用来自哪份文档、哪个章节是否取到了旧版本没有证据时是否明确说明缺少依据检索片段含有操作指令时是否会被误当成系统授权工具要有清楚的输入和失败返回把内部接口接给模型之前需要先整理工具的语义。接口能返回 JSON并不意味着模型就知道每个字段应该怎么填。原文采用的工具组织方式包括用urCLI 提供操作入口用 Skills 组织任务与能力说明再通过 MCP 等方式连接工具调用。不同入口最终仍需要落到可检查的业务请求。下面两张图展示了工具代码、参数说明和调用结果的组织方式示例任务是“毫秒时间戳转中文日期时间”。即使是时间转换也有容易出错的地方输入是秒还是毫秒时区是什么空值和非法值怎样返回放到设备查询里还会增加设备编号、时间范围、分页和单位等约束。工具契约应说清输入含义、单位、必填条件、返回结构及失败状态。参数合法性由程序验证不能只靠模型理解说明。涉及修改配置或控制设备的工具还需要明确确认流程和审计记录。AI 生成的工具代码也要经过检查和测试。一次示例调用成功只能证明该输入下的结果不能证明异常输入、权限边界和失败重试都已覆盖。控制面与执行面分开会话服务负责接收请求、组织上下文和调度任务工具运行时负责实际执行。将两者分开便于单独管理长任务、资源限制和故障恢复。原文讨论的架构可以按四层理解层次主要职责需要核对的边界控制面会话、Agent、上下文与任务编排当前身份、任务状态、授权与取消执行面运行时、脚本与工具执行资源、超时、文件和网络访问范围工具面Skills、MCP、CLI 与工具说明参数语义、返回结构、错误处理应用面业务系统、IoT 设备与外部入口数据权限、业务校验、操作结果例如一个报表任务卡住时需要能取消该任务、释放对应资源并让用户知道结果尚未完成。不能让模型继续输出“已生成报表”也不能让同一个任务无上限占用执行资源。Sandbox 用于约束执行环境但它不能替代业务权限校验。文件目录、网络访问、依赖安装、凭据使用和任务存续时间仍需要分别设置与验证。隔离机制是否有效要通过越界访问、超时和取消等测试确认。多入口共用一套业务能力下面的原始截图展示了本地 OpenClawMarvin通过联犀 Skills 查询平台应用与组织信息的过程。它证明的是这条查询链路的展示结果不代表本地助手因此获得全部业务权限。这类接入中本地助手可以承担交互与任务编排业务服务继续负责身份、数据范围和动作校验。Web、App、CLI 或语音入口也应遵循同一原则。需要特别区分查询与控制查询一次设备温度只产生读取请求调整阈值或下发设备命令会改变业务状态。后者需要明确目标设备、参数范围、确认方式和失败处理不能因为查询已经接通就认为控制链路也完成了验收。部署方式由数据与运维条件决定SaaS、私有化和混合部署各有适用条件。选型时可以把问题落到具体对象上原始文档、设备数据、会话与日志分别存放在哪里模型调用会带出哪些内容是否符合该项目的数据要求工具运行在哪个环境能访问哪些网络和目录谁负责升级、备份、故障恢复及权限维护是否私有化不能只看聊天页面部署在哪里。模型接口、对象存储、检索服务和工具运行时也需要一起核对。使用同一套平台服务更不等于不同组织可以互相访问资料。先用一个场景验证整条链路设备分析、报表组织、规则配置和报告审查都可以作为 AI 接入业务系统的切入点。以下是场景设计与验收示例并非承诺全部步骤都能自动完成。场景可以交给 AI 辅助的工作需要保留的核验设备分析整理查询条件、解释趋势、组织图表时间范围、单位、聚合口径与原始读数报表整理组合字段、生成摘要、标出异常项数据来源、计算过程与缺失项规则配置将自然语言要求整理为候选规则设备范围、阈值、执行权限与确认报告审查查找引用、比对条款、提出修订建议规约版本、对应位置与专业人员复核以农业大棚调参为例现场人员说“最近偏冷整体调高一点”系统还缺少目标区域、调整幅度、有效时间和约束条件。先把这些信息补齐再生成候选参数交由获准人员确认比直接让模型决定执行值更便于检查。报告审查也类似找到相关规约不等于已经证明文档有误。应保留条款版本、引用位置和判断依据让专业人员决定是否修改。上线前至少核对这些结果权限更换用户、项目或角色后查询与工具调用是否仍被正确限制。来源回答中的数字、文档引用和统计结论能否回查原始依据。执行参数错误、超时、取消与重试时是否返回真实状态并释放资源。操作查询、配置修改和设备控制是否有清楚的权限与确认边界。维护文档、工具和业务接口升级后旧配置与历史任务怎样处理。把一个有明确数据范围的场景跑通再逐步增加工具与入口。AI 可以改变交互方式企业系统里的权限、数据口径和执行责任仍需要落实到每一次请求中。
AI 能帮我们搭页面、写接口、补脚本。原型做出来以后工程问题才开始集中出现多个部门怎么共用工具拿谁的权限执行检索到的资料能不能给当前用户看一个脚本卡住会不会拖慢整个服务这些问题也是我们在联犀项目中组织 AI、SaaS 与 IoT 能力时需要处理的内容。下面结合已有界面与架构设计讨论权限、知识、工具和运行时怎样接到一起。截图保留当时版本的实际界面场景设计与已展示的操作分别说明。原型能跑离多人使用还有多远单人助手里使用者通常也是配置工具、管理资料的人。进入企业系统以后同一个问题可能需要经过组织、项目、角色和业务流程的共同约束。要核对的问题单人使用时多人业务系统中身份当前使用者当前用户、组织、项目与角色资料范围使用者提供的资料按权限筛选后的文档和业务数据工具调用使用者配置的工具工具权限与业务接口鉴权共同约束执行失败影响当前任务需要限制对其他用户和服务的影响结果验收使用者判断需要来源、状态、日志与业务核对区别不在于聊天窗口放在哪里而在于一次回答、一次工具调用能否沿着这些边界走完。可以先选一个小场景验证用户查询某个项目的设备运行情况。系统先确认用户身份和项目范围工具再读取获准的数据返回结果应包含查询时间、设备范围、统计口径和异常情况。模型把结果组织成文字或图表并不改变原始数据的归属。权限留在业务服务里AI 需要知道自己正在服务谁、处理哪个项目但提示词里的身份说明不能代替服务端鉴权。在已有 SaaS、IoT 系统中接入 AI可以先复用用户、角色、项目和设备的权限关系。一次调用需要核对四件事身份从哪里来由登录会话或受控的服务身份提供不能让模型自行填写身份后取得权限。对象是否属于当前范围设备、文档、报表是否在该用户获准访问的组织与项目中。动作是否获准允许读取状态不代表允许控制设备或修改业务配置。结果是否仍需过滤工具返回的数据、检索片段和引用来源也要符合当前用户的数据范围。例如用户让 AI“看看这个项目有哪些设备”工具应在业务接口已经约束的项目范围内查询。即便模型生成了另一个项目的编号服务端也应拒绝越权请求而不是相信模型已经检查过。这层约束适用于网页、CLI、本地助手等不同入口。入口可以不同业务接口的权限判断不能因此省略。知识检索和长期记忆分开组织企业 AI 往往同时接触知识库、会话记录、用户偏好和业务对象。它们更新的频率不同来源与可信程度也不同不宜全部当成一段长期提示词。原文中的 Hermes 记忆管理界面展示了 L1、L2 记忆层级和 Dream 运行入口。它用于说明近期交互与长期记忆可以分别组织界面本身不代表每条记忆都已经核实。设计这类链路时至少要考虑记忆的来源、更新与失效用户后来纠正的信息如何覆盖旧记录项目结束后相关上下文是否仍应进入新会话权限发生变化后旧记忆还能不能被装配进回答知识库则需要保留文档结构与来源。下面是联犀知识库工作台的实际界面左侧是文档目录中间是正文右侧是 AI 助手。阅读和提问放在同一工作区便于对照资料核验。验收时不要只问“回答通不通顺”。还应检查引用来自哪份文档、哪个章节是否取到了旧版本没有证据时是否明确说明缺少依据检索片段含有操作指令时是否会被误当成系统授权工具要有清楚的输入和失败返回把内部接口接给模型之前需要先整理工具的语义。接口能返回 JSON并不意味着模型就知道每个字段应该怎么填。原文采用的工具组织方式包括用urCLI 提供操作入口用 Skills 组织任务与能力说明再通过 MCP 等方式连接工具调用。不同入口最终仍需要落到可检查的业务请求。下面两张图展示了工具代码、参数说明和调用结果的组织方式示例任务是“毫秒时间戳转中文日期时间”。即使是时间转换也有容易出错的地方输入是秒还是毫秒时区是什么空值和非法值怎样返回放到设备查询里还会增加设备编号、时间范围、分页和单位等约束。工具契约应说清输入含义、单位、必填条件、返回结构及失败状态。参数合法性由程序验证不能只靠模型理解说明。涉及修改配置或控制设备的工具还需要明确确认流程和审计记录。AI 生成的工具代码也要经过检查和测试。一次示例调用成功只能证明该输入下的结果不能证明异常输入、权限边界和失败重试都已覆盖。控制面与执行面分开会话服务负责接收请求、组织上下文和调度任务工具运行时负责实际执行。将两者分开便于单独管理长任务、资源限制和故障恢复。原文讨论的架构可以按四层理解层次主要职责需要核对的边界控制面会话、Agent、上下文与任务编排当前身份、任务状态、授权与取消执行面运行时、脚本与工具执行资源、超时、文件和网络访问范围工具面Skills、MCP、CLI 与工具说明参数语义、返回结构、错误处理应用面业务系统、IoT 设备与外部入口数据权限、业务校验、操作结果例如一个报表任务卡住时需要能取消该任务、释放对应资源并让用户知道结果尚未完成。不能让模型继续输出“已生成报表”也不能让同一个任务无上限占用执行资源。Sandbox 用于约束执行环境但它不能替代业务权限校验。文件目录、网络访问、依赖安装、凭据使用和任务存续时间仍需要分别设置与验证。隔离机制是否有效要通过越界访问、超时和取消等测试确认。多入口共用一套业务能力下面的原始截图展示了本地 OpenClawMarvin通过联犀 Skills 查询平台应用与组织信息的过程。它证明的是这条查询链路的展示结果不代表本地助手因此获得全部业务权限。这类接入中本地助手可以承担交互与任务编排业务服务继续负责身份、数据范围和动作校验。Web、App、CLI 或语音入口也应遵循同一原则。需要特别区分查询与控制查询一次设备温度只产生读取请求调整阈值或下发设备命令会改变业务状态。后者需要明确目标设备、参数范围、确认方式和失败处理不能因为查询已经接通就认为控制链路也完成了验收。部署方式由数据与运维条件决定SaaS、私有化和混合部署各有适用条件。选型时可以把问题落到具体对象上原始文档、设备数据、会话与日志分别存放在哪里模型调用会带出哪些内容是否符合该项目的数据要求工具运行在哪个环境能访问哪些网络和目录谁负责升级、备份、故障恢复及权限维护是否私有化不能只看聊天页面部署在哪里。模型接口、对象存储、检索服务和工具运行时也需要一起核对。使用同一套平台服务更不等于不同组织可以互相访问资料。先用一个场景验证整条链路设备分析、报表组织、规则配置和报告审查都可以作为 AI 接入业务系统的切入点。以下是场景设计与验收示例并非承诺全部步骤都能自动完成。场景可以交给 AI 辅助的工作需要保留的核验设备分析整理查询条件、解释趋势、组织图表时间范围、单位、聚合口径与原始读数报表整理组合字段、生成摘要、标出异常项数据来源、计算过程与缺失项规则配置将自然语言要求整理为候选规则设备范围、阈值、执行权限与确认报告审查查找引用、比对条款、提出修订建议规约版本、对应位置与专业人员复核以农业大棚调参为例现场人员说“最近偏冷整体调高一点”系统还缺少目标区域、调整幅度、有效时间和约束条件。先把这些信息补齐再生成候选参数交由获准人员确认比直接让模型决定执行值更便于检查。报告审查也类似找到相关规约不等于已经证明文档有误。应保留条款版本、引用位置和判断依据让专业人员决定是否修改。上线前至少核对这些结果权限更换用户、项目或角色后查询与工具调用是否仍被正确限制。来源回答中的数字、文档引用和统计结论能否回查原始依据。执行参数错误、超时、取消与重试时是否返回真实状态并释放资源。操作查询、配置修改和设备控制是否有清楚的权限与确认边界。维护文档、工具和业务接口升级后旧配置与历史任务怎样处理。把一个有明确数据范围的场景跑通再逐步增加工具与入口。AI 可以改变交互方式企业系统里的权限、数据口径和执行责任仍需要落实到每一次请求中。
