注册 Agent、接 MCP 工具、关联知识和管理提示词，经常被当成一组配置页面。真正连进业务系统才会发现，可见的工具不一定能用，能连接也不一定有权查询，改完配置还可能影响正在运行的会话。
平台需要给这些关系一个稳定模型。否则每接一个场景，就得重做身份传递、依赖解析和错误处理。
定义应用里各对象的责任
应用提供业务入口，Agent 理解任务、选择动作并组织结果，工具执行明确能力，知识与指令帮助解释条件。访问凭证由执行侧管理，不和提示词放在一起。
工具发现、已配置、连接正常、业务验证通过分别展示。绿色“已连接”不能代替全部状态。MCP 统一了部分工具与上下文交互，租户范围、业务动作和用户授权仍需要平台落实。
配置发布形成可识别版本
运行不读取持续修改的草稿。指令、工具声明、知识索引与依赖绑定经校验后发布版本，任务启动时固定采用的版本，事件和产出都关联它。
固定的是配置含义，当前权限不能被冻结。用户被撤权、凭证被吊销，后续工具调用仍按实时授权判断。版本一致性与安全条件分别处理，不能因为任务开始时允许，就一直沿用到结束。
任务记录保留执行主体、配置版本、工具绑定版本和知识快照引用，不复制秘密值。身份或引用无法解析时明确失败，不回退到默认大权限。
工具请求经过同一个执行入口
模型提出能力与参数，执行器验证结构、工具绑定、动作、资源和当前身份，再取用对应凭证。凭证面向正确服务、作用域与生命周期，模型只获得任务所需的业务结果。
页面选择的新配置与真正执行的版本需要能核对。若变更下一轮生效，界面明确说明；若要求当前任务切换，则定义已有状态如何兼容，不能改一个下拉框就暗中替换执行依赖。
对写工具，操作标识与重试规则在业务适配器内固定。接口超时可能已经生效，不能让模型换一组参数继续尝试。
错误分类决定系统下一步
{
"kind": "authorization-denied",
"retryable": false,
"operation": "read-metrics",
"requestRef": "request-a",
"userMessage": "当前身份不能访问所选资源"
}这是业务包装层的错误约定，不是 MCP 原始错误格式。结构错误指出缺什么，授权拒绝停止同类重试，凭证过期要求重新授权。限流按等待信息与任务预算决定延后，可能有副作用的超时进入核对状态。
连接失败、业务拒绝和模型选错工具不能全变成“执行失败”。用户需要知道能改参数、补授权还是等待，研发也需要定位到具体调用。
日志关联任务、身份范围、工具、操作键和实际结果，不打印令牌或所有敏感输入。审计可解释授权依据，运行日志解释执行过程，二者相互引用。
用两种能力验证接入模型
接入初期可以用一个只读工具和一个支持幂等操作键的写工具检查。覆盖配置版本、撤权、参数失败、超时、重试与结果读回，不用注册几十个工具来证明平台完成。
这些行为成立后，新增能力只需声明与适配差异，继续使用同一身份、执行和错误路径。平台复用的是这套运行约定，而不只是工具注册页面。