从只读辅助开始逐步开放写操作，用明确的进入条件和退出机制约束迁移风险。
从现有服务能力开始
存量 Java 系统通常已经具备用户、权限、事务、审计和稳定 API。接入 Agent 时，应该让这些能力继续作为业务权威来源。模型负责理解和建议，业务系统负责决定动作是否允许和实际是否完成。
迁移目标不是把全部业务逻辑改写成提示词，而是找到适合自然语言入口的任务，并在可控范围逐步扩大能力。
第一阶段：只读辅助
选择规范查询、工单摘要和状态解释等只读场景。接入已有身份体系，限制知识范围，返回证据引用。即使只读，也需要控制敏感数据和外部模型使用范围。
进入下一阶段的条件是：固定样本覆盖主要任务；引用能够校验；权限测试通过；失败能够解释。若缺少这些条件，先修复基础链路，不急于增加自主执行。
可以把模型结果作为现有页面中的辅助内容，让用户保留原来的操作路径。这有利于观察价值，也使服务异常时可以退回已有界面。
第二阶段：生成待确认提案
模型整理工单标题、环境和现象，但不立即写入。服务端把建议转成可审阅提案，明确展示目标项目与影响。
提案需要契约版本和有效期，用户修改参数后重新校验。缺少必要信息时，停在补充输入，而不是用默认生产环境或默认负责人填满字段。
这一阶段可以观察提案采纳率和修改内容。采纳率需要明确分母，并区分用户未处理和明确拒绝；不能把所有未点击都算作模型失败。
第三阶段：受控写入
启用一个边界清楚的写操作，例如创建工单。采用具体提案审批、执行时重新鉴权、稳定操作 ID 和结果对账。只有完整验证响应丢失和重复请求后，才扩大写入范围。
提案生成 → 业务校验 → 用户确认
↓
审批与参数绑定
↓
幂等执行 → 对账 → 终态
不适合一开始开放任意数据库写入或任意命令执行。工具应使用现有领域服务，让原来的事务规则和审计继续生效。
若通过 MCP 对外开放能力，依据 MCP 授权规范处理协议接入，同时保留业务资源权限检查。
第四阶段：异步任务与有限自主
当确实存在多步骤、长等待和中途恢复需求时，引入持久化编排。先让固定工作流可靠执行，再对路径不确定的局部步骤增加 Agent 循环。
自主范围可以从“选择检索条件”开始，逐步扩大到“根据证据建议下一步”。高影响写操作是否自动执行，必须由业务风险和授权模型决定，不能因为模型升级就默认开放。
多个服务协作时，通过事件和稳定业务标识连接，避免长事务跨越模型调用。
每一阶段都需要退出机制
模型网关异常时，只读功能可以退回原页面和普通搜索；提案生成异常时允许人工填写；写入结果不明时暂停新增动作并对账；编排升级出现回归时，将新任务切回旧版本，处理中的任务按状态迁移。
回退不是只把前端按钮隐藏。已经创建的任务、待审批提案和进行中的操作都要有去向。
用变化触发架构演进
当单实例内存、连接池或模型配额成为瓶颈，先测量再选择扩容方式。只有模块资源争用、独立发布或隔离需求明确时，才考虑进一步拆服务。
这条路线让 Java 系统的事务和治理能力自然延伸到 AI 应用。每一步都有可展示的成果和清楚的停止条件，也便于判断下一轮工作应该增强模型能力，还是补齐工程基础。
