上周，正式版发出去了。
说是“正式版”，其实并没有什么特别隆重的仪式。无非就是把前面欠下的一些账先补了一遍：工具能力补齐、已知问题修掉、稳定性重新跑一轮，确认没那么容易崩了，再把版本推上去。
群里发了一条消息，大家开始重新上手去测。
如果只看动作，这不过是一次普通发布。但如果把这周发生的事放在一起看，会发现项目已经开始悄悄进入另一个阶段了。
前面那段时间，我们更像是在一边救火、一边补洞：哪里断了补哪里，哪里缺了接哪里。可这周之后，很多事情开始慢慢收拢——
我们不再只是继续“加功能”，而是开始更清楚地回答一个问题：
这个企业级 AI 产品，到底先靠什么走进企业，靠什么真正变成能卖的东西。
这件事，比多做几个功能更重要。
一、某个顽固的报错，终于把问题指到了真正的根上
这周最让人印象深的一件事，是一个拖了很久的老问题终于被挖出来了。
之前 Admin 后台在测试环境里一直报错。表面上看，是一堆 JSON 解析失败，页面一进去就满屏飘红。大家一开始都以为是数据格式有问题，或者是某个接口字段不对，来回翻了很多遍代码，也换过几种排查方式，但始终没找到真正原因。
后来重新顺着链路往下看，答案终于出来了。
问题不在 JSON，甚至不在前端本身。真正的问题是：Admin 这边复用了 Web Chat 那套认证体系，但它发请求时没有带飞书 token。
服务端收到这种请求后，返回的根本不是业务 JSON，而是 403，或者一段固定的失败 HTML 页面。前端再把这段 HTML 往 JSON 解析器里一塞，结果当然就是整页报错。
这类问题最烦的地方就在于：现象看起来像前端解析错误，但根因其实埋在认证链路和路由链路里。
也正因为这样，这次大家对 GPT-5.5 的体感开始明显变好了。它不一定最快，但它更细，能顺着现象往里钻，最后把问题落到真正的根因上。
这件事本身，比“哪个模型更强”更值得记。
因为在真实工程环境里，很多问题不是不会修，而是找不到真正该修的地方。而谁能更快把问题从“表面噪音”还原成“真实原因”，谁就更有价值。
这个问题定位清楚之后，后续方向也就顺了：
Admin 要补飞书认证授权；
后面会识别飞书角色；
只有管理员角色才能进入 Admin 后台；
现阶段测试先不锁死，先让团队正常体验和验证。
这一步看起来像是在修 Bug，其实是在补企业落地里最绕不过去的一层：权限和身份边界。
二、我们开始做一件更像“接管系统”的事，而不只是“对接系统”
这周还有一个很关键的进展，是“系统探索”这条线开始跑出一个小闭环了。
它的目标，不是普通意义上的接口对接，而是更进一步——让 AI 去主动摸清一个已有系统。
现在的流程大概是这样的：
在 Admin 后台录入一个目标系统的登录地址和一组凭证，后台就会起一个 worker，用这组凭证去登录目标系统。登录之后，它会像一个开着浏览器开发者工具的工程师一样，边操作页面，边监控请求，逐步去点页面上的各种按钮、抓接口、截图、记录链路。
最后，它会把抓到的内容分析整理成一组工具集。
这里最重要的，不是“抓到了接口”这件事本身，而是这套能力后面接了一个审核过程：
不是抓完就直接开放给用户，而是先进入后台审核，再决定哪些能力可以暴露给 Web Chat 或飞书端使用。
这就很关键了。
因为这说明这个东西已经不是一个“技术炫技小玩具”，而是在往一个企业能真正接受的方向长：
它能进入真实系统；
它能把散乱接口整理成可复用工具；
它还能被审核、被控制、被治理。
本地已经拿目前已有的系统跑了一遍。仓库、门店、订单之类的接口都被抓回来了，最后沉淀出二十多个工具。凭证只需要登录一次，后面加密保存，等工具接起来之后，再查门店、查库存、查订单，就不需要重新走页面流程了。
而且它还有一个挺实用的细节：可以通过提示词干预探索范围。
比如明确告诉它：
不要点系统配置；
不要碰高风险区域；
只抓普通业务功能接口。
这样它就不会在无关区域上浪费时间，也能少抓很多噪音。
这条线现在还早，但方向挺清楚了。因为企业真正在意的，从来不只是“你会不会聊天”，而是：
你能不能把我原来那些分散、老旧、没人讲得清的系统能力，重新整理成一个能被 AI 调用的新入口。
这件事要是做顺了，价值会很大。
三、Agent 这条线，这次不是普通重构，而是在纠偏
这周另一个分量很重的动作，是 Agent 底层逻辑被重新拉回正轨。
之前虽然已经用了 LangGraph，但落地方式其实并没有真正用上它最核心的能力。
简单说，就是外面看着像“图”，里面其实还是把一条固定流程硬编码进去了。ReAct 也是被塞在一个固定方法里跑，最后变成了一种“看起来用了框架，实际上还是直线流程”的状态。
前期这样做，能跑。但一旦往后做深，就会越来越别扭。
因为 LangGraph 真正有价值的那些东西——
循环图能力
checkpoint
断点恢复
人工审核暂停
更复杂的子图路由
之前基本都没吃上。
这意味着什么？
意味着你现在虽然能让 Agent 跑起来，但一旦涉及下面这些场景，就会越来越吃力：
执行到一半要暂停，等人审核；
某个节点失败后要恢复；
不同意图走不同子图；
多 Agent 协同分发；
垂直行业工作流配置化。
所以这次周末两天的重构，真正的意义不在“代码重写了一遍”，而在于：把 Agent 从“先凑合能跑”拉回到“底层方式是对的”。
现在新的结构下，图是真正可以循环的。不是单向往下跑到底，而是可以在满足条件时返回到某个节点重新处理。这就给后面的人工审核、断点恢复、子图路由留下了承接点。
同时，这次还顺手补了两层扩展能力：
1）Graph 编辑能力
后台已经开始具备图编辑的基础能力。后面做多 Agent 或者任务流，不一定都要靠硬编码堆，可以逐步往图配置上走。
2）节点动态加载
原来很多节点是写死在系统里的。现在开始支持把部分节点逻辑做成脚本，放进 Loader 的结构化数据里动态加载。这样以后要扩展某种节点，不一定每次都要重新编译发布，也可以通过脚本热加载的方式去做。
这一步特别重要。
因为一旦以后真的往企业垂直场景走，你不可能每来一个行业、每来一种审批流、每来一种业务链路，都重新硬编码一遍。最后一定得落到配置、脚本、扩展层上。
所以这次看起来是在重构 Agent，本质上是在为后面的工作流化、行业化、可配置化打底。
四、知识库也开始从“能召回”走向“该怎么接进主流程”
知识库这边，这周的重点也已经不再只是“能不能搜到内容”了，而是开始转向另一个更实在的问题：
这些召回出来的东西，到底该在什么时候、以什么方式，进入 Agent 的主流程。
现在知识库里已经有一部分文档了，包括简历、工作总结、会议记录，以及从文档里转出来的一些实体信息。召回测试也已经能跑出结果，能把某个人的简介、参与项目、工作内容这些信息捞回来。
但真正难的，从来不是“能捞回来”，而是：
什么时候该查知识库；
什么时候不该查；
查回来的内容怎么组装；
最后怎么交给大模型去做问答。
这次一个很关键的变化，是知识库后面会被放到专门的RAG 节点里处理。也就是说，它不再是默认每次都要走的一步，而是要通过意图判定决定是否触发。
比如用户明显是在问知识类问题，那就走 RAG；如果不是查询型意图，就不必每次都去捞知识库。
这件事听着不大，但本质上是在补“边界”。
因为只有当知识库变成一个受控节点，而不是一个无脑必经流程时，后面它的权限控制、范围控制、路由控制、结果治理，才真正做得起来。
另外，现在也已经看到一些很现实的问题：
切片 overlap 还偏小；
语义断裂、页面断裂还会出现；
整个处理链路对外部 API 依赖还是偏重；
改写、清洗、向量化、排序这些环节，后面还得继续调。
但这些问题反而说明：现在知识库终于进入“开始认真工程化”的阶段了。
五、大家开始越来越清楚：真正的主线其实没有那么多
今天这场会最有价值的地方，不是某一个技术点，而是大家开始把现阶段真正重要的事收拢出来了。
如果把整场讨论压缩一下，当前最核心的主线，其实就四件：
1. UI 改造
先把产品感拉起来。企业第一眼看到的不是底层架构，而是“这东西看起来像不像个成熟产品”。
2. 系统探索
让 AI 更快接管企业已有系统，而不是每次从零做对接。
3. 工作流 / Graph 完善
把通用 Agent 能力变成真正可配置、可扩展、可承接行业流程的底层。
4. 知识库接入
让企业里的文档、数据、沉淀内容，真正变成可调用、可问答、可治理的资产。
除此之外，安全和权限必须前置。这一块不是“有时间再补”，而是如果不先补，后面根本落不下去。
包括：
飞书角色权限
数据访问权限
工具分层
工具安装审核
知识库访问审核
后续审计能力
这些东西不一定每个都要一步到位，但方向必须先立住。
因为企业场景里，能力不受控，比能力不够更危险。
六、后续的商业路径已经更加清晰
今天还有一个很重要的变化，是大家对“后面到底怎么走”这件事，开始说得更透了。
五一之后，团队大概率会分两条线推进：
一条，继续做恒海内部深化；另一条，开始切进电商垂直领域。
这个判断很现实，也很对。
因为企业级 AI 这件事，表面上看像通用能力，但真到了交付阶段，你会发现每个行业的差异都非常大：
工作流不一样；
Skill 不一样；
工具不一样；
数据结构不一样；
权限要求不一样；
交付边界也不一样。
如果什么行业都想同时铺，最后结果通常不是“覆盖很广”，而是服务成本越来越高，团队永远被拖在定制项目里。
所以更合理的方式，是先抓一个行业，把它打穿。
比如电商这条线，往下拆就会很明确：
选品可能需要一套工具和 Skill；
采购是另一套；
物流交付又是另一套；
每个节点背后都可能需要独立能力支撑。
这时候，底层就不能再是一锅粥。Base 层、工具层、Skill 层、行业扩展层，后面都要逐步拆开。
最好是像积木一样：
底层 Base 稳定迭代；
上层行业能力按需插拔；
工具和 Skill 动态装载；
Base 升级时，不影响行业层已有扩展。
这套想法今天已经说得比较明白了。而一旦这个结构真理顺，项目就有可能从“卖服务”往“卖产品”慢慢转过去。
这是两个完全不同的阶段。
七、正式版发出去之后，项目不只是继续堆东西了
回头看这一周，其实发生的事情很多：
正式版发了；
老 Bug 找到根因了；
Admin 权限链路开始理顺了；
系统探索跑出闭环了；
Agent 底层被重新拉回正轨；
Graph、节点、RAG、意图路由这些结构开始成型；
知识库开始真正往主流程里接；
UI、系统探索、工作流、知识库四条主线被明确下来；
五一之后的垂直行业路径也开始有了方向。
这些事单独看，好像还是一堆具体问题。但合在一起，其实是在回答同一个问题：
一个企业级 AI 产品，怎样才算真正开始成形？
不是模型更强一点，也不是功能再多一点。
而是它开始慢慢具备这些东西：
看起来像产品；
接得进企业系统；
跑得起真实流程；
管得住权限和风险；
接得住企业知识和数据；
底层结构能继续扩展，而不是越做越乱。
这周最重要的，不是又做完了多少事。而是大家终于开始更像是在走一条清楚的主线，而不是四处补火。
忙完这一周，再回头看，才会有一种感觉：
之前像是在救火，现在才有点像，真的在做一个会长出来的东西。
这，是第十四天。
《从0到1：企业级AI项目迭代日记》记录一个企业级 AI 项目从创意、架构到落地的真实过程。不讲神话，只记录进化。
如果你也在做企业 AI 落地，欢迎留言来聊。或者，把这篇转发给一个正在踩同样坑的朋友。
