内部 AI 工具体系

判断什么该交给 Agent，什么不该。

2026 年夏天，我在一家早期科技公司任 AI Native 实习生，直接向 CEO 汇报，负责 AI-Native 产品与内部工具。这一页保留真实的判断结构：每个决定当时的处境、约束、判断与代价。

01问题Problem

公司开始用 AI，但供给、介入与采纳都没有被定义。

模型能力的使用缺少统一的边界，Agent 进入工作流的方式没有定义，组织也没有可靠的使用事实。这不是一个工具缺口。我没有把问题收敛成「做一个内部工具」，而是拆成三层，三层互相约束：供给没有边界会失控，介入没有闭环会失责，采纳没有事实基线会变成口号。

决策与执行分层。控制面负责身份、权限、预算与审计；执行层只执行已经做出的策略。

先判断介入形式。对每个工作流区分替代执行、辅助生成与结果校验，并写明人保留在哪个闭环节点。

把采纳当作产品问题。建立使用事实、能力准备度与可复用知识的沉淀路径，让供给对应真实的需求。

02决策Decisions

实现细节大多不能公开，判断可以。没有代价的决定，不值得被写成案例。

叫停负收益的自研框架

处境: 组织已有一项持续投入的多 Agent 协作方向。最自然的动作是继续修补。
约束: 我不是最终决策者，只能提供足以改变投资判断、并且可以复现的证据。
判断: 用同类产品的实测复现问题：多 Agent 在缺少确定性调度时，会进入不可检测、不可恢复的语义死锁。据此向 CEO 论证继续投入的边际收益为负。结论被采纳，这条方向停止投入。
代价: 证据是在并行工作里逐步积累的。如果先定义「什么证据足以下结论」，可以更早收口。

场景切分与人机分工

内部大模型调用网关

处境: 如果不设统一的入口，每个 Agent 都会各自实现一套身份、权限与预算。
约束: 入口要兼容多类客户端与上游通路；外部身份协议的字段也不归我们控制。
判断: 主导网关的需求定义、核心实体关系与用户组权限设计，把身份、权限、预算与审计收敛到网关层。划分边界的依据是所有权与变更速率，而不是今天的数据是否刚好一致。
代价: 前期多出一层看似冗余的映射，用灵活性换确定性。初期把配额与用户组的边界后补，造成过一次返工。

五周，从需求到上线

处境: 交付窗口短，工作线并行。任何一条从零自研，都会挤占判断与验收的时间。
约束: 团队没有余量长期维护新的轮子。「先可用」和「架构完美」在这个窗口里是冲突的。
判断: 默认先找现有实现，再过三道筛：它是否扛掉了最不值得自己写的部分；改动集中在边界层还是核心层；它隐含的身份与权限假设，是否适合多人场景。并且提前写下退役条件。
代价: 过渡件往往比计划活得更久。分叉之后，上游的更新也不再自动获得。

使用基线调研

处境: 一种常见的判断是：模型继续变强之后，体验与采纳的问题会自然减弱。
约束: 我不能靠立场赢得讨论，也不能让一次宣讲替代真实的使用证据。
判断: 推动使用基线调研，按具体工具拆分使用频率。结果显示，阻塞采纳的不是模型上限，而是稳定性、上下文连续性、工作流连接与概念理解。这四项共同指向使用者对 AI 输出的信任度。我据此把 enablement 从「推广活动」重新定义为供需对齐的机制。
代价: 先调研、后演示，放慢了短期的推进节奏。第一次讨论也没有可以立即宣布的成果。

03过程Process

我的工作路径是：需求调研，规格与实体关系，任务拆解，Coding Agent 实现，再由我负责变更管理、测试范围、回归与验收。与工程侧按领域的所有权分工，而不是按页面或功能切割责任。这段实习里我写的代码不多，写的规格很多。这不是角色的限制，而是 Agent 参与开发之后，最重要的产品控制面。

04交付Delivery

05回顾Retrospective

初期按「先跑起来」推进，把配额与用户组的边界后补，最终造成返工。多租户系统的第一个实体不是功能，是边界。

我也曾把采纳理解成「做完再去讲」。调研之后才明白，它首先是产品问题：没有人会因为公司在推 AI，就去忍受一个会断连的工具。如果重来，组织调研会发生在第一周。

披露说明：公开版本不呈现公司身份、内部系统名称、供应商、代码与文档原文。数字与简历一致。