Windmill AI ChatCopilot上下文窗口工程ai-chat 技能文档的源码级实践指南【免费下载链接】windmillOpen-source developer platform to power your entire infra and turn scripts into webhooks, workflows and UIs. Fastest workflow engine (13x vs Airflow). Open-source alternative to Retool and Temporal.项目地址: https://gitcode.com/GitHub_Trending/wi/windmillWindmill 的前端 AI 聊天copilot是一个多轮工具调用循环每一轮迭代都会重新发送系统提示词与全部工具 schema因此“上下文窗口纪律”直接决定了它是否溢出、是否触发压缩、以及成本曲线。本文基于仓库内技能文档 ai-chat/SKILL.md 展开结合 ai_evals 基准框架 与 chat 目录 的生产源码说明如何为 chat 的 tools、prompts、上下文窗口管理做出可度量、可回归的改动。读完你应能掌握变更前后的 A/B 基准流程、finalContextTokens指标的底层含义以及“工具即永久性税”这一上下文纪律在源码中的落点。适用场景与改动边界技能文档在 front-matter 中明确了触发边界当你需要修改frontend/src/lib/components/copilot/chat下的聊天工具、系统提示词或工具结果结构或者调整 chat 管理上下文窗口的方式时都应遵循本文描述的纪律。文档开头还特别强调 global 模式全局 copilot可跨工作区创建/编辑 draft是重点优化对象——这正是 global/core.ts 体量最大的工具集合所在。改动前后必须跑 ai_evals A/B文档第一条规则是硬性流程任何上下文或行为改动都必须对受影响模式跑一次ai_evalsA/B 才能合入并且要为“恰好你改动的东西”添加或调整用例case。基准框架如何工作ai_evals/README.md 定义了这套小型基准运行器覆盖五种生产模式cli、flow、script、app、global——其中global正是本技能文档的主战场。基准“始终测试当前 checkout 中的生产 prompts、tools 与 guidance”每次尝试执行三步真实生产路径 → 确定性验证 → LLM 评审judge。完整命令参考安装ai_evals独立安装前端模式还需要前端依赖cd ai_evals bun install cd frontend bun install常用命令来自 ai_evals/README.mdcd ai_evals bun run cli -- models # 列出模型别名 bun run cli -- cases # 列出用例 bun run cli -- cases flow # 列出 flow 模式用例 bun run cli -- run flow # 跑整个 flow 模式 bun run cli -- run flow flow-test4-order-processing-loop --model opus bun run cli -- run flow flow-test0-sum-two-numbers --models haiku,opus,4o bun run cli -- run flow flow-test0-sum-two-numbers --runs 3 --verbose bun run cli -- run flow --record # 追加一条紧凑历史到 history/*.jsonl bun run cli -- run global global-test1-script-create # global 模式本技能的主模式关键run选项--runs n每个用例重复 n 次--model alias/--models a,b,c选择被测模型或顺序跑多个模型别名--skip-judge跳过 LLM 评审做纯确定性运行--execution-only只要求模型/代理/前端循环跑通跳过 validator、工具期望、后端产物验证与评审--record仅对整套件运行追加一条追踪摘要到ai_evals/history/mode.jsonl--backend-validation mode对script/flow用例的可选后端冒烟验证off或preview模型别名当前包括haiku、sonnet、opus、4o、gpt-5.5、gemini-3-flash-preview、gemini-3.1-pro-preview、deepseek-v4-flash、deepseek-v4-pro。注意前端模式flow/script/app/global可走 Anthropic、OpenAI、Gemini、DeepSeek 后端judge 模型独立配置默认claude-sonnet-4-6。A/B 的具体做法与留痕按技能文档要求在你的改动之前和之后用相同模型、相同用例各跑一次受影响模式。--record会为整套件运行向 ai_evals/history/global.jsonl 等文件追加一行紧凑摘要每行包含运行元数据createdAt、gitSha、mode、runModel、judgeModel套件总量caseCount、attemptCount、passedAttempts、passRate、averageDurationMs、averageJudgeScore平均 token 用量averageTokenUsagePerAttempt、averageTokenUsagePerPassedAttempt逐用例指标与failedCaseIds一个值得注意的细节CLI 头部的时长与 token 均值只统计通过的尝试全量均值仍被记录以便审计失败原因但不会让失败尝试扭曲成功成本对比——这正是做上下文优化 A/B 时避免噪声的方法。先测窗口占用再测累计 token技能文档的优化次序很明确先优化finalContextTokens窗口占用率再优化累计 prompt token。finalContextTokens的源码定义从源码结构看这个指标并非“总消耗”而是循环最后一次模型请求的输入 token 数即会话结束时的窗口占用快照基准侧类型定义在 types.ts“Input tokens on the last model request of the loop”它由 baseEvalRunner.ts 从result.lastIterationUsage?.prompt映射而来命中hitMaxIterations与正常结束两条路径都如此见同文件 L203上游的lastIterationUsage来自生产循环 chatLoop.ts每次模型响应把 usage 赋给lastIterationUsage最终随addedMessages、tokenUsage一起返回chatLoop.ts#L631。这个口径的选择有原因驱动**溢出与压缩compaction**的是最后一次请求把窗口填了多少而不是历史累计了多少。累计 prompt token 则是成本视角的次级指标。结果聚合与 UI 侧的对应物基准结果聚合在 results.ts把每个 attempt 的finalContextTokens累加进finalContextTotal并更新均值使“改动前后窗口占用是否下降”成为可 diff 的数字生产前端同样暴露窗口占用AIChatManager.svelte.ts 用lastIterationUsage.prompt completion更新contextUsage驱动 UI 上的上下文用量指示ContextUsageIndicator.svelte。因此“先测窗口”不是抽象口号同一份lastIterationUsage数据既喂给基准的finalContextTokens也喂给生产 UI 的用量条两条路径口径一致。上下文纪律每个工具、每个参数都是“永久性税”技能文档指出主导性的固定成本是每轮迭代的开销系统提示词加上所有工具 schema会在循环的每次迭代被重发。由此推导出两条可操作的纪律。纪律一删除死参数而非留着它们“每个工具和每个参数都是永久性税。要为每一个辩护并度量它一个多余的 locate 往返的成本可能超过它省下的读取。” 从源码结构看这正是 chat 工具集需要持续审查的原因global 模式在 global/core.ts 中集中定义了大量工具工作区条目、变量、datatable、preview tabs 等任何一个工具参数都会在每一轮请求里重复计费。基准框架为此提供了精确的断言手段——toolExpect.toolCallArgs支持fieldMustBeAbsent: trueai_evals/README.md断言“任何一次录制的调用都不得携带该字段”显式null也算携带。这适合部分更新类工具模型无法读到的字段如果还被提交上去本身就是一次失败。纪律二工具结果返回最小信息绝不回显模型已拥有的内容文档给出的经典反例写工具在模型刚刚生成完整个产物后把完整编辑后的 artifact原样返回——正确做法是只返回{ success, message }。文档还特别警告了一个真实发生过的回归模式当你触碰共享写助手时必须对所有经由它路由的写工具重新检查该不变式——回显曾经通过共享重构回归过。这个共享助手就是文档点名的finishAppDraftWrite。在 global/core.ts 中它定义于第 4886 行并被 6 个写工具调用L5898、L6203、L6233、L6307、L6341、L6453——这正印证了文档的担忧面改这一个函数的返回形状会同时改变 6 个工具的每轮上下文开销任何一个漏掉最小化原则都会让“税”重新涨回去。系统提示词与工具描述是“可基准化的表面”技能文档最后一节把 prompt 和 tool description 提升到与工具实现同等地位它们对行为的影响力不亚于工具本身且用同样的方式可基准化。文档举了两个例子一条“宣传了截断”的描述会让模型自我设限self-limit——描述文本本身改变了行为“路径约定块”path-conventions block决定了 draft 落地的位置。因此 prompt/描述的修改应被视为真实变更并纳入 A/B纯 prompt 改动也是合理的、可度量的改进。由于 ai_evals 的基准“始终测试当前 checkout 中的生产 prompts 与 tools”ai_evals/README.md一次纯文案修改跑一遍bun run cli -- run global就能给出 passRate 与 token 指标的前后对比与代码改动使用完全相同的验证路径。落款一条可执行的改动清单综合技能文档与仓库证据改动 copilot chat 时的检查清单是确定受影响模式通常是global先跑一次基线bun run cli -- run global必要时--record留痕改动 tools/prompts/结果形状若触碰共享写助手如finishAppDraftWrite对其全部下游写工具复查“最小返回”不变式为恰好改动的行为新增/调整 casecase 格式与validate规则见 ai_evals/README.md 的 “Case Format” 一节例如 global 模式可断言 draft 类型/路径/语言、必备/禁用片段、禁用 draft 路径改动后用同模型、同用例复跑优先看finalContextTokens窗口占用再看累计 prompt token 与 passRate通过后再考虑性能之外的体验项——顺序不可颠倒因为窗口占用是溢出、压缩与成本的共同上游。需要注意的适用前提以上流程依赖本仓库的ai_evals工具链与前端生产代码路径模型别名、judge 模型与用例集均以当前 checkout 的 ai_evals/README.md 和ai_evals/cases/为准docs/ai-agent-evals.md描述的是产品内 AI Agent 评测功能与本文的 copilot 开发基准是两套机制不要混淆。【免费下载链接】windmillOpen-source developer platform to power your entire infra and turn scripts into webhooks, workflows and UIs. Fastest workflow engine (13x vs Airflow). Open-source alternative to Retool and Temporal.项目地址: https://gitcode.com/GitHub_Trending/wi/windmill创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考