2 篇博文 含有标签「configuration」

大多数工程团队都能准确地告诉你哪个环境变量在控制他们的数据库连接池。但几乎没有人能告诉你现在是哪个版本的 system prompt 在处理 90% 的流量 —— 或者自上一次收到模型行为投诉以来发生了哪些变化。

这就是 AI 配置足迹（AI configuration footprint）问题。构建基于 LLM 功能的团队会积累一个隐形的配置层 —— 模型选择、采样参数（sampling parameters）、system prompts、工具 schemas、重试预算 —— 这些配置决定了他们的产品在生产环境中的行为。这一层的大部分内容都没有记录在案（system of record）。它们通过直接修改代码、交付电子表格或 Slack 消息进行更新。当出现问题时，没有人能说清楚发生了什么变化。

这不是流程问题，而是架构问题。解决方案需要以成熟团队对待环境配置、功能旗标（feature flags）和基础设施即代码（infrastructure-as-code）同样的严谨态度来处理 AI 配置。

当产品团队第一次需要针对每个用户的智能体（agent）行为时，通常会有人说“我们应该进行微调”或“让我们接入持久化内存”。一周后，他们拥有了向量数据库、反馈循环流水线，以及监控学习状态漂移的路线图项。他们构建了一个机器学习系统来解决一个在十有八九的情况下其实只是配置文件的问题。

看看用户真正想要的是什么：更简洁的回答、要点列表而非散文、免责声明中包含我的公司名称、默认使用我偏好的模型、100 美元以下不要转接到人工、这是我本周正在处理的项目、永远不要使用表情符号。这些都不需要模型去学习任何东西。它需要的是设置（settings）。Dotfile 模式——一个版本化的、声明式的、针对每个用户的配置库——在四十年前就为 shell、编辑器和 CLI 解决了这个问题，而这正是 2026 年 AI 智能体的正确形态。