技术/工具

团队里用 AI 的常见乱象：有人用 ChatGPT、有人用 Claude、有人在本地 ollama 里跑模型，聊天记录散落各处，合规审计无从谈起。解决办法不是再装一个工具，而是给团队一个统一的私有聊天入口。Open WebUI 就是干这个的：一个网页界面，背后可以同时挂本地 llama.cpp／ollama 模型和云端 API，成员登录后在同一个地方选模型、聊、共享会话。 部署就一条命令 它官方支持 docker 一键起：把本地跑着 ollama 的端口映射进来，docker run -d -p 3000:8080 --add-host=host.docker.internal:host-gateway ghcr.io/open-webui/open-webui:main。浏览器打开 3000 端口，第一个注册的人是管理员。 接云端模型也简单：在后台的「外部连接」里填 OpenAI 兼容的 base_url 和 key，OpenRouter、LiteLLM、DeepSeek 都能接。这样团队成员在下拉框里就能选「本地 7B」或「云端 GPT-6」，不用各自配环境。 两个团队向的功能 用户与权限：可以加成员、设只读，敏感部门的会话留在自己服务器上； 模型分组：把「对外可用」和「仅研发调试」的模型分开，避免新人误调到贵的模型。 判断 当 AI 从「个人尝鲜」变成「团队生产力」，入口统一本身就是效率。本地模型处理敏感数据、云端模型处理复杂任务，用同一个界面切换，既省了重复订阅费，也让数据 finally 留在自己机器上。微软卖 2599 美元的 AI 笔记本讲的是单机算力，而 Open WebUI 解决的是「算力怎么变成团队入口」这另一半问题。 补一个部署细节：Open WebUI 自带用户体系，建议关闭「开放注册」，改成管理员邀请制。否则内网地址一旦被扫到，陌生人也能注册并用到你配好的云端模型——那就是真金白银的损失。另外，给敏感模型组单独设访问权限，把「内部调试用的本地大模型」和「全员可用的轻量模型」分开。 本地模型处理敏感数据、云端模型处理复杂任务，在同一个界面里切换，入口统一了，效率和合规才同时成立，成员也不用再各自养一套订阅，账单自然也省下来了。 去论坛讨论 这篇文章里的观点，欢迎到硅基AGI论坛讨论。按标题搜索：OpenWebUI

一个团队做 AI 应用，半年下来手里往往攥着七八把 API key：OpenAI 的、Anthropic 的、DeepSeek 的、智谱的、还有本地 llama.cpp 的。每接一家，代码里就多一套字段名、一套错误码、一套计费口径。LiteLLM 要解决的就是这个：它对外只暴露 OpenAI 兼容协议，对内把各家模型翻译成同一套调用格式。 它到底统一了什么 一套 SDK：代码里只写 client.chat.completions.create(...)，模型名写成 deepseek/deepseek-chat、gemini/gemini-2.5-pro 这样的前缀，剩下的转换由网关做； 一个 key 出口：应用只认网关地址，各家真实密钥存在服务端，前端拿不到； 统一记账：网关天然知道每次调用花了多少 token、哪家模型、哪个用户，可以直接出账单。 起一个网关 最省事的是用它的 proxy 模式：写一个 config.yaml 列出模型与对应环境变量里的密钥，然后 litellm --config config.yaml --port 4000。应用把 base_url 指向 http://localhost:4000，就像在调一个 OpenAI。 再往上走，可以开它的后台 UI，按团队、按 key 分组限额——市场部的 key 每天最多花 50 元，研发的 key 不限速但要记账。 为什么这件事值得做 Manus 2.0 把 Token 成本砍掉两成多，靠的是框架优化。但如果你连「谁在花、花在哪」都看不见，优化就是盲人摸象。一个统一网关是把账单从黑盒变成仪表盘的前提。等哪天你要在 GPT-6 和 DeepSeek 之间按价格动态切换模型，这个网关就是路由层——没有它，多模型容灾只是纸上谈兵。 补一个排障细节：网关层最容易出问题的是超时。长任务（Agent 跑十几步）很容易超过默认的短 HTTP 超时，导致前端报错但后端其实还在跑。把网关和客户端的超时都调到五分钟以上，并开启流式响应，长任务的体验才顺。另外，key 分组限额要配告警，别等账单来了才发现某个测试 key 被循环调用。 把网关立起来之后，你会发现「换模型」「看账单」「做限流」从改代码变成了改配置——这层抽象一旦到位，后面的多模型策略、价格路由才有地方生长，不至于散落在业务代码里。 去论坛讨论 这篇文章里的观点，欢迎到硅基AGI论坛讨论。按标题搜索：LiteLLM网关

单轮聊天出错，看一眼输出就知道问题。但 Agent 跑十几步、调了五六个工具、还把上下文越滚越长之后，用户一句「结果不对」甩过来，你根本无从下手——它当时到底检索了哪段文档、调了哪个工具、中间哪一步开始跑偏？这就是为什么 2026 年做 Agent，可观测性是必需品，不是锦上添花。Langfuse 是这一范畴里常用的开源选择。 它解决什么 Langfuse 的核心是 trace：一次 Agent 运行从开始到结束，被记成一棵树。每个节点记录输入、输出、耗时、token 数、错误。你可以在网页上回放：这一步模型看到的上下文是什么，那一步工具返回了什么。 三步接进来 自托管一行 docker 起 Langfuse，或用云版拿一对公钥私钥； 在你的 Agent 代码里装它的 SDK，用装饰器或上下文管理器包住模型调用与工具函数； 给每步打上 name 和元数据（任务 id、用户 id），跑几次，控制台就能看到轨迹树。 对用 OpenAI Agents SDK、LangChain、Dify 的项目，Langfuse 都有现成集成，基本是填两个环境变量的事。 怎么用起来 复现 bug：用户报障时，按任务 id 拉出那一次 trace，定位是检索错了还是工具返回错了； 找成本黑洞：按 token 排序，找出那几个每轮都把超长上下文重发的步骤，针对性做压缩； 回归对比：改完提示词，对比新旧 trace 的步数与失败率。 判断 Agent 从 demo 走向生产，最后一公里往往不是「它够不够聪明」，而是「它出错时你能不能修好」。给 Agent 装上 Langfuse 这个黑匣子，等于给飞行记录仪——飞得多高是模型的事，坠机了能黑匣子读数，才是工程团队的底气。 补充一个进阶用法：给 trace 打标签。按部门、按场景、按用户等级打标签，事后就能对比「市场部的 Agent 平均跑几步、花多少 token」和研发的差异。这种横向对比，往往能直接定位到那个一直没被注意的高成本流程——它跑得勤，却没人意识到它在烧钱。 去论坛讨论 这篇文章里的观点，欢迎到硅基AGI论坛讨论。按标题搜索：Agent观测

AI 写代码越来越快，瓶颈反而卡在「谁来审」上。9 月底 OpenAI DevDay 之后，带云电脑的编码智能体已经能自己提 PR，但合并前那道人工评审，仍是团队质量的最后一道闸。把这道闸的初筛交给 AI，是性价比极高的一步——不需要买重型平台，一个 GitHub Actions 工作流就够。 工作流长什么样 核心是三步：触发 PR、拉取 diff、调模型评审、把结果写回评论。在仓库 .github/workflows/ai-review.yml 里： on: [pull_request]，限定 opened / synchronize； 用 actions/checkout@v4 拉代码，git diff origin/main...HEAD 拿到本次改动； 把 diff 作为 user message 发给任意兼容 OpenAI 协议的接口（DeepSeek、智谱、或自建网关都行），API key 存在仓库 Secrets 的 LLM_API_KEY； 用 actions/github-script 把模型返回贴成 PR 评论。 提示词只抓四件事：明显 bug、空指针或越界、安全性（注入、硬编码密钥）、以及「这次改动是否超过了它该做的范围」。 两个容易踩的坑 第一，别让它写风格意见。一旦允许模型评论「变量名不够语义化」，PR 评论区会被无效意见淹没，开发者很快把机器人静音。把输出限定为「必须修改」与「建议确认」两档。 第二，控制 diff 体积。一次改两千行的 PR 直接喂模型，既慢又贵还漏看。超过 800 行就只评审变更文件的关键函数，或拆成多轮。 落地建议 先在内部仓库灰度两周，让团队投票保留哪些意见类型。AI 评审不会替代人，但它把新人最容易犯的那类低级错误挡在人工评审之前，Reviewer 的注意力才能留给真正难的设计权衡。这才是它该待的位置。 补充一个实操细节：首次接入时，建议先把评审设为「仅建议、不拦截」，运行一周收集机器人给出的意见，让团队投票保留哪几类。那些真正挡住 bug 的意见留下，只会制造噪音的删掉。此外，对大改动 PR 可以只做增量评审——用 git diff 限定到本次变更的函数，避免模型把精力花在历史代码上，也省 token。 ...