从一家主要依赖多维表的物流企业出发，我把问题收敛到一款采购工作台：业务人员能直接上手，Agent 能在规则内协作，采购业务库留在本地。
笔者所在的物流企业数字化程度不高，没有专业 SRM，采购人员主要靠多维表和 Excel 管理业务数据，也会与已有业务系统协作。产品要解决的第一个问题很具体：怎样让分散的采购明细变成可以持续处理的工作。
先接住工作流，再增加智能
日常工作从请购明细开始。采购员导入 NC 请购单，筛选并认领自己负责的需求，补充供应商和预计发货时间，再写下下一步动作；采购订单进来后，再核对它与请购的关系并持续跟进交付状态。数据往往已经存在，麻烦在于每次处理都要重新找、重新判断，还要记住跟进到哪一步。
所以第一步是把已有表格中的工作接起来，暂不铺开一套完整 SRM。工作台把需求分成“待筛选”和“我的需求”，再把订单与需求关联。每行数据都有清楚的归属和当前状态，重新导入时也会保留已经认领的状态与跟进信息。
这个范围选择影响产品形态。它沿用采购员熟悉的 Excel 和表格操作，把工作放进 Harness 右侧栏；现阶段先服务请购整理与订单跟进，不要求团队先迁移全部采购流程。对数字化基础有限的团队来说，先减少每天反复整理和查找的工作，比一开始追求系统覆盖面更实际。
让 AI 操作落到表格里的业务对象
AI 智能表格的价值，在于让自然语言指令直接作用于表格。采购员可以用自然语言生成筛选规则、填色规则，也可以创建逐行计算的 AI 字段。模型负责理解指令并生成结构化结果；宿主服务检查字段和规则是否有效，表格再应用这些结果。AI 输出因此进入现有的表格工作，采购员不必再把一段回答手动复制到业务数据中。
Agent 也通过受限的采购工具读取和更新需求。面板与 Agent 最终调用同一套宿主采购服务，因此认领、跟进和权限边界不必在两套入口分别实现。Agent 可以查询、认领、更新跟进字段；采购订单状态仍由工作台的订单流程处理。这个边界让自动化动作更清楚，也便于采购员判断哪些变化来自自己、哪些由 Agent 执行。
判断业务与处理例外
确认需求归属，判断供应商与交付安排，处理需要经验和授权的决定。
执行明确的工作任务
按授权查询需求、认领明细或更新跟进字段，并反馈查询或更新结果。
采购数据与业务规则集中在宿主服务；工具接口约束 Agent 能执行的操作。
面向业务人员，复杂度要留在产品里
插件面向采购人员，他们不需要专业 IT 背景。对他们来说，表格能不能读、导入有没有预览、点错后会怎样，远比底层用了什么模型更直接。产品沿用 Excel 导入和熟悉的列视图，把自然语言指令转成可以检查的规则；AI 输出格式不符合约束时会报错，不会直接写成采购业务变更。
“即插即用”需要让用户沿着已有工作习惯开始，把数据建模、规则编写和流程配置留在产品设计中。插件运行在 DeepSeek Harness 里，安装和模型账户依赖宿主环境；因此，这里的即插即用指采购操作路径尽量简单，运行仍有明确前提。
本地存储，不等于所有 AI 计算都在本机
出于数据安全考虑，采购业务数据库由本地 Harness 宿主管理。导入的采购明细、订单和基础资料保存在宿主存储域；表格列配置以及 AI 字段定义和结果则保存在当前浏览器。它们的数据位置和用途并不相同。
模型调用也有明确边界：AI 筛选和填色会发送用户指令及可用字段信息；AI 字段计算会发送参与计算的选定行数据，一次最多 50 行。当前 AI 功能使用 Harness 的 deepseek-account 模型服务。产品可以准确地说采购数据库保存在本地；若承诺任何采购数据都不会离开本机，就与当前实现不符。企业若要求字段级数据也不能发送到外部模型，就需要本地推理，或进一步限制 AI 可读取的字段。
或最多 50 行选定字段
“业务库本地存储”和“AI 推理数据不外发”是两项不同的安全要求。
仍需继续验证的产品问题
当前持久化模型按单机、单采购员设计，AI 字段配置也只保存在当前浏览器。Agent 能访问宿主侧采购记录，但不会自动读取浏览器里的 AI 字段结果。团队协作、跨设备视图和字段级数据策略，都需要在更大范围使用前补齐。
这些限制也给出了产品演进的先后顺序：先验证采购员是否愿意在工作台里完成请购整理与交付跟进，再根据真实协作方式处理身份、权限和共享；涉及敏感数据的 AI 能力，则先说明输入范围和推理路径，再决定是否需要本地模型。
AI 进入业务工作流，起点是一个具体业务对象和下一步动作。对这款采购工作台来说，这个对象是请购明细；表格负责承载人工判断，Agent 负责执行受限任务，宿主服务把两者连接起来。