给每个人一个 Agent：实例、身份和生命周期怎么设计

一个 Agent 应用开放给多人，实例怎么分，会直接影响会话、文件、业务身份和升级。共享页面不等于共享助手，给每人一个目录也不等于完成业务隔离。

我的设计把模板、逻辑实例和计算资源分别管理。模板复用能力，实例持久保存用户状态，执行时才分配环境。

怎样把一个工作空间交付成别人能使用的 AI 应用

工作空间里的应用能跑，往往依赖很多默认条件：工具已经连接，模型已经配置，目录里还有以前试验留下的文件。复制目录能把页面交过去，却不一定交付了可维护的应用。

我把发布包、部署与运行数据拆开。别人收到的应是可识别的应用版本，目标环境自行绑定资源，用户数据不跟着应用更新被覆盖。

设计业务用户的 Agent 界面时，第一屏放什么讨论了好几次。聊天框容易理解，可每天来处理告警、看运行和做审批的人，未必想从一个空白输入框开始。

我把主对话、业务状态页和伴随式助手放回实际任务里看。它们可以共存，没有一种形态适合承载所有工作。

用户拿到一份报告后说：“以后每天早上都做一份。”保存这段提示词还不够。补跑日期、模板更新、通知失败和历史追溯，都会让每天一次变成不同的执行。

我把模板、计划、运行和产出分开管理。模板定义怎么做，计划定义何时触发和使用哪个版本，运行固定实际输入，产出关联这一次执行。

最近准备业务助手演示，从收到告警到生成处理报告，几步连起来很自然。真正做设计时，难的是每一步采用什么依据、哪些结论还不确定，以及动作失败后报告应该怎么写。

这里用设备能耗异常举例。设备与动作是通用示意，分析建议、创建工单和设备控制不能被当成同一种权限。

接第二种 Agent 实现时，会话、工具调用、权限请求和取消的差异就开始影响界面。若每种实现都带来一套聊天状态，接入数量增加以后，界面与执行侧很难一起维护。

最近研究 ACP，我更关注它能把哪些交互变成共同约定。这里的 ACP 是 Agent Client Protocol，面向客户端与 Agent 通信，不是所有同名缩写的协议。

平台需要给这些关系一个稳定模型。否则每接一个场景，就得重做身份传递、依赖解析和错误处理。