从单机协同到内网多 Agent 协作架构
本机已实现三个 Agent 的协同工作，下一步计划将该模式扩展至公司内网。核心目标是让员工在各自终端使用 AI 处理需求分析、文案撰写等任务，而将涉及店铺查询、商品上架、修改、发货及对账等具体业务操作，统一交由一台长期运行的内网电脑执行。
初期无需购置高配硬件或急于部署私有大模型，现有的 M2 芯片、8GB 内存 Mac mini 即可作为业务执行节点进行试点。建设重点在于构建公司共用的业务工具库、权限管理体系及任务记录机制。
需明确区分三个维度的部署策略：Agent 的分布位置（单机或多机）、模型的运行环境（云端或本地）以及业务操作的发起端。所谓“走向内网多 Agent 协同”，并非强制将所有模型本地化，而是采用混合架构：员工端 Agent 利用云端模型进行理解与分析，内网节点负责程序运行与任务执行。
图 1 从一台电脑里的协作，扩展到多台电脑共用业务执行节点
核心挑战：从个人工作流到企业级服务
单人使用多 Agent 主要解决任务分工问题，如需求理解、代码处理和结果检查。但当多名员工同时使用时，面临密钥管理、并发冲突、任务持久性及审计追溯等新挑战。
为解决上述问题，需建立统一的执行服务。员工在熟悉的环境中通过 Agent 工作，店铺操作则进入统一入口，由标准化程序进行检查和执行。这种模式支持业务能力的复用，便于快速接入新员工。
Mac mini 的角色定位：业务执行节点
初期设想是通过 SSH 控制内网 Mac mini 运行 Ollama 或私有模型，但这并非最优解。对于亚马逊运营场景，标题、五点描述、图片等材料通常在员工端已准备完毕，内网节点的核心任务是执行既定规则下的上架、库存修改、货件操作及财务数据请求。
此类工作大部分可固化为程序逻辑，包括授权获取、参数检查、请求提交、限流处理及结果保存。基于 Amazon SP-API SDK 构建业务客户端，可避免每次操作都依赖模型重新生成代码。因此，Mac mini 的角色应定位为保存并运行业务执行程序的服务端，而非推理节点。
图 2 云端模型、本地客户端、内网服务和 Amazon 各自承担的工作
连接方式：从 SSH 到受控业务入口
云端模型无法直接访问局域网，需通过员工端 Agent 客户端发起调用。初期可使用 SSH 进行连接调试和程序部署，但在多人长期使用场景下，应提供固定的业务入口，如商品查询、上架提交、库存修改、货件创建及结算报告下载。
固定入口有助于明确权限控制和操作审计。员工清楚自身调用的功能，服务端也能针对每个动作进行严格的权限校验。
任务执行流程与状态管理
以商品上架为例，员工端 Agent 整理包含店铺、站点、SKU、父子关系、标题、价格、库存及图片地址的交付包。内网节点收到后，首先校验材料完整性及操作者权限，若存在缺项则返回具体错误；校验通过后，交由业务客户端执行。
任务持久化与断点续传
系统为每个任务分配唯一任务号，所有请求、返回、重试及读取操作均关联该 ID。即使员工电脑断开连接，服务端仍继续处理已接收的任务。重新连接后，员工可通过任务号查询进度或结果。
图 3 一次上架任务从提交到验收的过程，断线后按任务号接续
结果验证与业务语义定义
“完成”不仅指接口接收请求，还需确认业务最终状态。程序需持续查询处理结果，验证属性、报价及商品状态，并将生效情况反馈给员工。
- 查询类任务：返回数据及其时间范围。
- 修改类任务：记录修改前、修改后及读回结果。
- 发货类任务：保存货件标识及后续所需信息。
业务含义应由公司预先定义并写入工具，而非依赖模型临场判断。财务对账、结算报告下载等功能也可纳入同一入口，但需注意银行付款、税务申报等非 SP-API 范畴的操作需单独对接相应系统。
权限管控、冲突处理与数据安全
统一节点的核心价值在于多人协作下的规范化管理。店铺凭据由服务端统一保管，员工通过身份认证提交任务。服务端负责检查操作权限，即使 Agent 提出超范围指令，程序也应予以拒绝。
并发冲突与任务审计
针对多人同时修改同一 SKU 的情况，服务端需实施排队、加锁或版本检查机制，避免覆盖冲突，并防止任务重复执行。同时，系统需记录详细的任务日志，包括提出人、店铺、任务范围、修改内容及执行结果，确保操作可追溯，不受员工更换设备或 Agent 的影响。
数据出境合规性
业务服务内网化不代表数据完全隔离。若员工将订单、报表等信息发送至云端模型分析，数据仍会进入云服务。公司可通过工具层规则过滤敏感字段，或对必须留存在本地的数据评估私有模型方案。
硬件选型与实施路线建议
鉴于主要负载为请求转发、任务调度及接口调用，现有 M2、8GB Mac mini 足以胜任初期测试。应根据实际并发量、报表大小及常驻程序数量监测性能瓶颈，再决定是否需要升级硬件。若未来需运行声音克隆、图像识别或本地代码模型，可将业务节点与模型节点分离，按需增加资源。
私有模型的引入应基于实际需求，如数据合规要求、高频任务的成本效益分析等。建议先通过真实业务样本测试本地模型的成功率、速度及维护成本，再行采购。
分阶段实施策略
- 第一阶段：跑通完整的商品上架流程，包括材料提交、字段检查、正式执行、读回验收及结果返回。以此验证连接稳定性、权限控制及异常恢复机制。
- 第二阶段：逐步接入商品查询、库存修改、货件管理及财务对账功能。利用代码 Agent 辅助开发和测试新模块。
- 第三阶段：在日常使用中持续评估各功能模块是否真正减少重复操作，确保技术投入转化为实际管理价值。
理想的.company AI 部署模式是：员工保留个性化的 Agent 前端，公司逐步积累标准化的后端执行能力。业务操作统一经由服务层处理，确保结果可查、记录留存。先利用现有设备实现协作闭环，再根据业务发展决定后续硬件投入。
文中涉及的接口接入、授权和限流，可参阅 Amazon 官方文档：
SP-API 的连接与授权 · SP-API SDK · SP-API 使用计划与限流