当一个内容系统从 Laravel 管理后台扩展到移动应用和 AI 代理时，团队很容易为每个新入口单独写一套接口，再把权限、校验和业务规则复制一遍。Laravel CMS 项目 kitloom 的做法是不新建第二套后端：它把后台视为“单一写入路径”，让 Filament、Nova、REST API、AI agent 和移动端都只作为入口层调用同一套写入服务。这个选择减少了规则不一致，也让 AI agent 的权限边界回到既有用户体系。
后台不是界面，而是唯一写入路径
kitloom 是一个基于 Laravel 的 CMS，可使用 Filament 或 Nova 作为管理后台，站点侧可以使用 Blade、Vue 或 React。项目团队很早就确定了一条规则：admin 不是一个 UI，而是一条写入路径。每个页面、接口、工具和 App 都只是这条写入路径前面的入口。
传统做法里，后台页面可能直接在控制器中调用模型创建或更新数据。新增 API 后，同样的逻辑会在 API 控制器里再写一遍；新增 AI 工具后，又会出现第三套调用方式。kitloom 把写操作集中到 writer。以文章创建为例，不同入口不直接调用 Post::create，也不在控制器里执行 $post->update，而是统一使用 PostWriter 的 create 方法，并传入当前操作者 $actor。
Writer 负责完成一组固定动作：
- 保证 slug 唯一；
- 补齐日期等字段；
- 分配分类或术语；
- 清理无权限用户提交的 HTML，避免脚本内容混入；
- 触发 PostSaved、PostPublished 等事件；
- 拒绝当前操作者无权执行的动作。
这样一来，Filament 创建页、Nova 资源、REST API 的 PostsController，以及 AI agent 的 create_content 工具，实际上都走同一条路径。文章发布规则、作者和编辑权限、唯一性校验，只在一处维护。如果 slug 生成逻辑需要修复，四个入口会同时生效。
同样的思路也被用于电商场景。站点结账表单和手机端 POST /checkout 都进入 Checkout::placeOrder()；站点购物车和移动端购物车报价都使用同一个 Cart。优惠券、配送区域、“满 $60 免运费”等规则只写一次，避免后台可用、App 不可用的差异。
AI Agent 的边界：不是新权限系统，而是复用用户权限
AI agent 接入业务系统时，最难处理的往往不是调用模型，而是它到底能碰什么数据、能执行哪些写操作。素材给出的答案是：模块本身不感知 agent 是否存在。每个模块只提供可被调用的类，并给它打上 AgentTool::TAG 标签。AI 模块收集这些标签，再通过 MCP 提供给 agent。
工具本身也被设计成一个很薄的入口。以重定向创建工具为例，它只声明名称、描述、权限、是否会写入，并在 handle 方法中调用已有的 Redirections 服务。真正的创建逻辑仍在原业务类中。素材提到，一个工具大约四十行代码，其中大部分是描述信息。
这种设计的重点在于边界：
- 权限字段直接指向模块既有权限，而不是为 agent 另建一套；
- writes 方法标明该工具是否会执行写操作；
- handle 接收参数和已认证的 actor，再交给原有业务逻辑；
- 如果没有 AI 模块，标签不会被读取，原系统也不会因此受影响。
标签机制还用于账户区块、通知主题、Webhook 主题、后台列表列和权限等跨模块扩展。素材提到，grep -rn ‘const TAG’ 被团队当作扩展点目录。
因为工具最终仍调用 writer，而 writer 已经检查“这个用户是否可以做这件事”，agent 的安全模型就落在既有用户权限上。素材称，目前系统共有 209 个工具，覆盖内容、SEO、重定向和 404 日志、菜单、表单及其消息、商城商品与订单、预订、翻译、备份、Site Health 等模块。多数工具只有几十行，因为底层逻辑早已存在。编辑也可以在活动日志中查看 agent 实际执行了什么。
移动端复用同一数据模型，后端工作量下降
移动端是这条架构的另一个受益方。kitloom 的站点主题使用 Vue 或 React，并基于 Inertia 返回数据。团队将页面数据以 JSON 形式公开：请求页面时带上 Accept: application/json，就能得到主题渲染所用的数据，包括商品、分类筛选、搜索结果和首页内容。这个能力最初不是为移动端设计，却成为手机应用接入的关键。
在应用侧，移动端是一个 Expo / React Native 项目，可服务不同 kitloom 商店。配置文件写入站点地址、名称、颜色和图标后，再通过 EAS 在商店所有者自己的 Apple 和 Google 账号下构建。应用功能包括首页横幅与货架、使用站点筛选器的目录、带图集和评论的商品页、购物车、三步结账、用户账户，以及订单发货推送。
服务端新增的 mobile-apps 模块约 2,200 行 PHP 代码，另加测试。素材给出的原因并不复杂：结账、购物车、商品、账户等能力已经存在于原有写入路径和数据模型中，移动端不需要重新搭建后端。团队还提到，移动端后端接入花了两天。
对 AI 编程落地的启示
这件事对行业最重要的提示，不是 AI agent 能调用多少工具，而是它如何被放进既有工程边界。许多团队在接入 AI 时倾向于单独建一组端点，结果是权限、校验和发布流出现多份副本。一旦业务规则变化，维护成本会上升。
kitloom 的做法把 AI agent 当成普通调用方，而不是特殊系统。它通过标签暴露能力，通过工具描述约束调用方式，通过既有权限系统限制操作者，通过统一写入路径保证校验和事件一致。对需要同时运营后台、网站、App 和 AI 助手的团队来说，这种架构比“为 AI 单独做接口”更可控。
当 AI 开始承担补全 meta、处理 404、查询经营数据等具体工作时，工程系统真正需要的是明确的责任边界。谁调用、是否有权调用、调用后触发哪些校验和日志，都必须有唯一答案。一条写入路径的价值，正在于把这些答案集中在同一个地方。
原创文章，作者：点点，如若转载，请注明出处：https://www.dian8dian.com/ba-ai-agent-jie-jin-xian-you-laravel-hou-tai-yi-tiao-xie-ru
