前言：让工具调用拥有可以解释的责任边界

一个 Agent 可以准确理解“替客户退回这笔订单”，也可以顺利调用退款工具，却仍然完成一次越权操作。理解文本、找到接口、生成符合 JSON Schema 的参数，只证明请求在语法上有意义。企业还需要知道：这次调用代表哪个人，由哪个程序执行，属于哪个租户，针对哪一笔订单，谁批准了什么，执行时授权是否仍然有效，以及事故后能否还原判断过程。

作者 Aias00 是 Apache ShenYu PMC 成员。个人长期参与 Apache ShenYu 社区工作，也在 Go、Java 与 Agent 相关工程中反复遇到同一种错位：网关已经认证，服务就默认信任全部请求；模型已经确认，业务就默认具备用户授权。系统上线后才发现，身份被压缩成一个全局 API Key，租户成为客户端可改的字段，审批退化成聊天记录里的一个“同意”。这本书试图把这些容易混在一起的问题拆成可验证的工程契约。

本书接续执行沙箱、AI 网关和知识检索的工程路线，但关注另一个边界。沙箱限制程序能接触的计算环境，AI 网关管理模型入口、配额和路由，检索系统约束文档可见性。本书关心 Agent 代表谁，对哪个业务对象做什么，以及这种权利怎样被委托、收紧、批准、撤回和审计。网络层的可达性与业务层的允许是两件不同的事实。即使工具只在内部网络，也必须回答对象授权问题。

阅读时请保留三个习惯。第一，把身份、意图与权限分别表达；用户说了什么不会自动改变访问控制规则。第二，把授权判断放在能够看到权威业务对象的位置；代理可以预筛选，业务服务仍然需要承担最终判断。第三，让每一项安全声明对应一个会失败的实验。如果删除一条校验后没有测试变红，团队可能还没有证明自己理解了那个边界。

随书实验分成两条路径。第一条在 Go 进程中运行三个真实 HTTP 服务，用 Ed25519 签名凭据、固定 JWKS、在线撤权状态与内存事务构造可控实验。这个教学 issuer 不是 OAuth 授权服务器，也不是 OpenID Connect 提供方；自定义的 /delegate 不是标准 token exchange。第二条在 GitHub Actions 的隔离容器中运行 Keycloak，实际获取 discovery、JWKS 和 client credentials 令牌，验证服务身份接入。我们没有实现浏览器用户登录、Authorization Code + PKCE、刷新令牌、DPoP 或完整 OAuth 委托链，相关内容会明确作为设计解释。

所有示例密码和服务密钥都是公开的开发凭据。宿主实验只监听环回地址；Keycloak 容器也只映射环回端口。实验状态保存在内存，重启会清空，不可承担生产退款。正因为边界被写清，读者才能把实验结论带回自己的环境，而不会把一个演示误认为成熟身份平台。

建议先运行第一章的测试，再顺序阅读身份、授权、审批、撤权与审计。熟悉 Java 的读者可以把 Go HTTP handler 对照 Spring Security 的资源服务器过滤器和业务 service 理解；熟悉网关的读者则应特别注意业务服务承担的二次验证。每章都有失败案例、实验入口与边界说明，最后提供迁移设计和评审练习。书末的完整代码附录在构建时直接读取仓库文件，网页、EPUB 与实验下载来自同一份源文。