帮老大处理内部文件时，我发现最麻烦的不是模型不聪明，而是它把「帮我看看」这句话当成可以直接读整个数据库的指令。那次之后我开始琢磨，权限其实已经给够了，但模型不知道「到哪为止」。
真实场景里，问题通常卡在三个地方：用户输入藏着多重指令、工具调用时没有 scope 限制、执行完没有可追溯记录。靠 Prompt 收窄范围只能管一时，接口层面的显式守卫才更持久。
我判断这套做法在处理敏感文件或跨系统操作时效果最明显，但具体到你的产品还要看数据敏感度和用户量。
用户输入该怎么解析成固定 JSON？
把用户原始输入先扔进结构化解析器，要求返回固定 JSON，字段包含 intent、target、constraints。判断做对了的标准是：解析后的 JSON 里每个字段都有值，且 target 能对应到你系统里真实存在的对象。
操作位置：在 API 网关或第一层路由里加中间件。可以用任何支持 JSON Schema 的库，先定义好必填字段和敏感词黑名单。
上下文注入层如何把 token 控制在 30% 以内？
只把当前任务需要的上下文切片注入模型，而不是把整个历史一股脑塞进去。判断标准是：注入的 token 数是否小于原始上下文的 30%，且没有包含其他用户的 ID 或文件路径。
这里有个小坑：如果你的上下文来自多个数据源，建议在注入前给每条记录打上 owner 标记，防止跨用户泄露。
举个具体例子：原始上下文 10000 tokens，包含用户 A 的 10 条聊天记录和用户 B 的 3 个文件路径。注入时只保留用户 A 当前任务相关的 2800 tokens（intent 匹配部分），比例正好 28%，同时过滤掉所有其他用户 ID。
工具调用前怎么加权限白名单？
给每个工具单独声明允许的 action 和 resource scope，模型只能在白名单内选择。判断做对了的标准是：模型尝试调用未声明权限的工具时，系统直接返回 403 而不是执行。
操作位置：在工具注册表里加 permission 字段，调用前再做一次二次校验。建议先从邮件、文件读写这类高风险工具开始收紧。
逐步确认层
对任何写操作或高风险读操作，强制走「预览 → 用户确认 → 执行」三步。判断标准是：关键操作前是否生成了人类可读的执行计划，且用户有明确的「拒绝」按钮。
可追溯记录层
所有输入、上下文、工具调用、确认结果都写入结构化日志，并关联到用户会话 ID。判断标准是：能按用户 ID 在 5 秒内查出某次调用的完整决策链。
落地顺序建议
我验证过先做工具权限层和逐步确认层成本最低。建议第一周只改这两个，跑通后再补输入规范和日志。整个过程用户可能多等几秒，但能把越权风险明显降低。
可直接复制的检查清单（建议做成 Notion 模板或代码注释）：
- 输入是否强制包含「操作对象」和「预期结果」？
- 工具是否都显式声明了 read-only / write 权限？
- 写操作前是否生成可读计划并提供拒绝入口？
- 日志是否包含模型决策依据而非仅最终输出？
FAQ
Q: 这 5 个组件是不是只适合复杂 Agent？
A: 不只适合。哪怕只是个简单的聊天总结功能，加上输入规范和记录层也能明显降低幻觉和越权风险。
Q: 实现这些组件需要重构现有代码吗？
A: 大部分可以做成中间件，先在 API 网关层加输入规范和日志，再逐步把工具调用收紧到权限白名单。
Q: 如果用户体验会变慢怎么办？
A: 把确认步骤做成可选的「快速模式」，默认只对写操作和跨域访问强制确认，平衡安全与效率。
你现在最想先把哪个组件加到自己的产品里？