Kilo Code 功能提案机制与特性路线图解析：从 MCP 企业管控到 Agent 可观测性与基准评测-平芜编程栈

Kilo Code 功能提案机制与特性路线图解析：从 MCP 企业管控到 Agent 可观测性与基准评测

【免费下载链接】kilocodeKilo is the all-in-one agentic engineering platform. Build, ship, and iterate faster with the most popular open source coding agent.项目地址: https://gitcode.com/GitHub_Trending/ki/kilocode

Kilo 是开源的全栈 agentic 工程平台，其设计过程本身也在仓库中公开演进。packages/kilo-docs/pages/contributing/features/index.md 是功能提案（Feature Proposals）的索引页，集中登记了四项处于不同实施阶段的设计提案，并定义了统一的提案模板。本文以此文档为骨架，逐条展开其索引的四项提案、提案生命周期状态机与模板写作规范，并结合仓库源码（工作流、核心实现）补充纵深细节。读完你既能快速理解 Kilo Code 当前正在规划的能力方向，也能直接套用其提案模板参与功能设计讨论。

一、功能提案页是什么：规划文档而非现状文档

索引页开篇即明确一条重要边界：packages/kilo-docs/pages/contributing/features/下的页面是设计提案与路线图，属于"规划文档（planning documents）"，不是当前状态架构参考（not current-state architecture references）。每一页都会在文档顶部（title 附近的 Status callout）记录自身实施状态，读者必须先读状态再读内容，避免把规划当成已上线能力。

当前索引共登记四项提案：

特性	状态	描述
Enterprise MCP Controls	Proposal	面向 MCP 服务器配置的组织级策略管控
Onboarding Improvements	Partial	欢迎页已完成的工作与拟议的新手引导改进
Agent Observability	Partial	现有运行指标与规划的 agent 质量信号
Benchmarking	Partial	现有 smoke-eval 证据与更广泛的评测路线图

四项提案中仅 Enterprise MCP Controls 处于纯 Proposal 阶段（尚无对应实现），其余三项均为 Partial——即已有部分能力落地、剩余部分仍在路线图。

二、提案生命周期：四种状态与使用时机

索引页指向的提案模板定义了完整的状态机，每个提案页必须在标题附近放置可见的 Status callout，且只能使用以下四种生命周期标签之一：

状态	使用时机
`Proposal`	仅设计，无对应实现存在
`Partial`	部分已发布；页面明确区分当前行为与路线图
`Historical`	页面仅为设计历史保留；实现已迁移到别处或发生实质性变化
`Superseded`	页面已被其他提案或实现参考取代

对Partial页面有一条硬性纪律：必须分别使用"当前实现"与"路线图"两张表格，严禁把已发布行为与暂定的 schema、端点、命令或发布声明混在一起。这一规则与 Kilo 仓库对"事实准确性"的一贯要求一致——例如packages/core中所有面向用户的命令与配置均有对应测试约束（见 packages/core/test 下大量session-*.test.ts、tool-*.test.ts等），文档写作同样不允许未经验证的能力被写成现状。

模板的固定章节结构依次为：Status 指引 → Overview（问题与方案、目标与边界）→ Requirements / Non-requirements → Current implementation（Partial 专用）→ Roadmap → System design → Scope and implementation → Compliance considerations → Future work。其中 Compliance considerations 一节要求写明安全、隐私、数据处理与 SOC 2 相关考量，体现了该仓库对合规维度的一贯关注。

三、Enterprise MCP Controls：一份典型的纯设计提案

该提案是四项中唯一的纯 Proposal 状态，其 Status callout 明确声明：目前尚不存在组织级 MCP 白名单实现，文中 schema、端点、仪表板流程与客户端执行策略全部是暂定（tentative）设计。

3.1 问题与 MVP 需求

开发人员可以自行配置 MCP 服务器（含 marketplace 服务器与自定义服务器），而企业客户需要组织策略来控制其开发者可以使用哪些 MCP 服务器。提案为此引入组织托管的白名单（allowlist）机制，MVP 需求分为两块：

Dashboard 应用侧：为组织管理员提供 MCP 策略配置区；展示 marketplace MCP 服务器并允许勾选批准项；默认策略为 disabled，若启用则先默认选中 marketplace MCP 服务器以避免意外破坏；白名单变更需写入审计日志；允许组织成员在 dashboard 中配置已批准的服务器。
客户端行为侧：组织策略 disabled 时保持现有本地 MCP 行为不变；策略 enabled 时，用"按组织+成员作用域的 dashboard 托管配置"替换本地 MCP 配置；不得激活或使用未获准的本地 MCP 条目；客户端若在策略启用期间仍检测到未获准的本地条目，可展示非阻塞的策略反馈，且这些条目无需出现在可激活的 MCP 选项中；策略启用时，扩展市场配置 UI 替换为指向 dashboard 的链接。

3.2 系统设计对比图与暂定 schema

提案用两张流程对比图说明配置来源的变化。当前世界（enterprise-mcp-controls-today.png）中，活跃 MCP 服务器的工具从Project mcp.json 与 Global mcp.json加载配置；启用企业控制后（enterprise-mcp-controls-with-ent-control.png），本地两个 mcp.json 文件被红色叉号标记废弃，配置改由Kilo Backend下发，客户端不再使用终端用户文件系统中的定义。

提案的暂定 schema 分三层（模板中均以 warning callout 标注"尚未发布，名称、存储布局、加密方式与 API 形态可能随实现评审变化"）：

组织设置保存白名单策略：

const OrganizationSettings_MCPControls = z.object({ mcp_controls_enabled: z.boolean().optional(), mcp_controls_allowed_marketplace_servers: z.string().optional(), })

dashboard 托管的成员配置可能需要加密存储：

create table if not exists organization_member_mcp_configs ( id uuid not null default uuid_generate_v4(), organization_id uuid not null references organizations(id), kilo_user_id text not null references kilocode_users(id), config bytea not null, created_at timestamptz not null default now() )

成员配置的载荷形状可从一个数组起步：

const OrganizationMemberMCPConfig = z .object({ mcp_id: z.string(), parameters: z.record(z.string(), z.string()) }) .array()

3.3 暂定的 dashboard 与 API 面

表面	拟议行为
`/organizations/:id/mcp-control`	让所有者管理白名单、成员配置已批准的 MCP 服务器
`GET /api/marketplace/mcps`	为策略 UI 拉取 marketplace MCP 列表
组织设置 API	读取与更新启用状态与白名单
成员 MCP 配置 API	存储加密的已批准 MCP 配置

提案特意声明这些路由与端点是"实现设计的占位符，不作为可用 API 文档化"。实施计划按后端（策略 schema、加密成员配置存储、审计日志、组织/成员 API）、Dashboard（管理员白名单 UI、成员配置 UI）、客户端（拉取策略配置、忽略未获准本地条目、链接 dashboard 配置）三块切分，未来工作则包括组织自定义 MCP 服务器、项目级 MCP 配置与按用户/项目/MCP 服务器分组的工具调用审计报告。

四、Onboarding Improvements：Partial 状态的新手引导路线图

该提案的 Status callout 说明：欢迎页工作已存在；starter 卡片、交互式教程、变更日志、provider 设置调整与漏斗事件在标记为 current 之前仍属路线图项。

4.1 当前实现与路线图

当前实现仅一项：欢迎页（Welcome screen）——已有的首跑界面为新用户提供起始上下文。路线图则列出六项规划能力：starter 提示卡片（用上下文动作 + codicon 视觉替换通用提示）、交互式教程、教程完成状态（避免反复展示已完成或已跳过的教程）、产品内变更日志、Kilo provider 设置布局优化（把 provider 设置动作放到相关字段旁以提升可发现性）、以及 onboarding 分析（跟踪新手进度与后续产品参与度）。

4.2 拟议的欢迎页扩展：starter 提示卡片

卡片应使用 VS Code codicons 而非 emoji，选中后把提示填入聊天输入框：

卡片	提示
Debug helper	Help me fix a bug in my code
Feature builder	Add a new feature to my project
Documentation	Generate documentation for this file
Code review	Review my current changes by running`git diff`and analyzing output

4.3 拟议的教程流程与分析事件

教程流程的五个步骤聚焦界面与输入区：Welcome（说明短向导用途）、Agent/模式选择（当前选择器 UI）、侧栏与 MCP（指向历史与 MCP 配置）、开始聊天（说明提示与文件引用）、starter 提示（展示常见首任务）。提案特别注明：早期设计笔记中提到的 Chat / Edit / Architect 模式名称应视为历史示例而非当前 UI 要求。

分析事件仍属路线图项，最终名称与载荷需经遥测评审：

漏斗	候选事件
Onboarding	`onboarding.started`、`onboarding.tutorial.completed`、`onboarding.tutorial.skipped`、`onboarding.prompt.selected`、`onboarding.finished`
Engagement	`chat.started`、`mode.changed`、`changelog.viewed`、`changelog.dismissed`、`provider.configured`、`file.referenced`、`mcp.configured`

未来工作包括漏斗流失分析、项目感知的首动作推荐、高级功能的渐进式披露、按角色区分的引导流程、基于项目代码的提示建议以及团队/仓库专属引导。

五、Agent Observability：现有可观测性与 agent 行为信号路线图

该提案聚焦 agentic 编码系统的可观测性：此类系统组合了模型请求、工具执行、文件变更与外部 API 调用，传统请求指标只能捕获硬故障，还需要 agent 行为信号来排查循环（loops）、劣化会话与不良结果。其云服务上下文可参考 Cloud Platform observability（文档中指向/docs/contributing/architecture/cloud-platform#observability）。

5.1 现有能力清单

能力	状态	说明
API 指标摄取	Current	运行请求指标摄取已存在
会话指标摄取	Current	会话级摄取已存在
Burn-rate 告警评估	Current	告警评估基于已存指标运行
告警配置存储	Current	告警配置存储已存在
Analytics Engine 存储	Current	API 与会话指标数据集已存在
导出管道	Current infrastructure	指标导出基础设施已存在，供下游分析
逐条消息反馈	Current	显式用户反馈信号已存在

5.2 路线图与操作指标维度

路线图目标包括：振荡检测（重复或交替的 agent 动作）、唯一文件进度指标（会话中触及的文件）、唯一工具进度指标（工具多样性与重复操作）、会话终止分类（完成/放弃/超时/错误）以及高阶结果分析（超越硬错误的可用性与任务成功判断）。

操作指标路线图建议在现有摄取与告警基础设施之上构建仪表板与服务等级目标，任何字段在投入生产分析前都应先验证覆盖度。API 指标的候选维度：Provider、Model、Tool、Latency、成功/失败、错误类型、Token 数、客户端来源；会话指标的候选聚合：会话时长、首个模型响应耗时、轮次与工具调用、按类型错误、消耗 Token、上下文压缩频率、终止原因。

5.3 告警策略与 agent 行为信号

Burn-rate 评估基础设施已存在。拟议的告警路由应仅对使用 Kilo Gateway 的推荐模型进行传呼，其他条件则建工单或保持禁用：

窗口	Burn rate	拟议动作
5 min	14.4x	重大故障传呼
30 min	6x	事件传呼
6 hr	1x	行为变化建工单

初始行为分析聚焦重复操作与进度信号：相同工具调用（同工具同参数的重复动作）、相同失败调用（重复相同失败的多次重试）、振荡模式（无进展的交替状态）、触及的唯一文件数（会话变更广度）、使用的唯一工具数（与重复操作对比进度）、重复/唯一比率（识别可能卡住的会话）。

结果路线图则承认：硬错误与行为指标并不能证明用户成功，后期工作可把逐条消息的显式反馈与会话终止分析及其他结果信号结合；离线模型与 agent 对比属于 Benchmarking 的范畴。

六、Benchmarking：受检证据与评测路线图

Benchmarking 提案要回答两个核心问题：同一 Kilo Code agent 下不同模型如何对比；同一模型下不同 agent 或 Kilo Code 版本如何对比。它明确区分"受检仓库证据"与"路线图"，且不保证私有评测工具、外部适配器或示例命令对贡献者可用，并与生产可观测性划清界限：可观测性监控真实会话，基准评测运行受控评估任务。

6.1 现有证据（Partial）

能力	状态	证据与限制
Harbor 对向 smoke eval	Current workflow	`.github/workflows/smoke-test.yml`检出私有`Kilo-Org/kilo-bench`，安装依赖，经仓库脚本运行两个 smoke 任务
CLI 发布 smoke 覆盖	Current workflow	工作流可测试最新 npm CLI 或指定发布资产
Smoke 结果产物	Current workflow	上传结果、轨迹与 agent 安装文件供检查
云 model eval ingest	Current service	静态源码检查发现`services/model-eval-ingest/`推广同步面
私有 kilo-bench 内部	未在本仓库验证	私有仓库脚本、适配器行为与支持的本地命令超出受检文档范围
生产启用状态	未验证	静态源码无法证明部署、回滚、留存或厂商配置

6.2 受检的 smoke-eval 工作流

仓库中的 .github/workflows/smoke-test.yml 与文档描述完全吻合，可作源码级佐证：工作流支持workflow_dispatch（可选传入cli_version）与workflow_call（发布草稿资产上传后由 publish.yml 调用），依赖三个 Secret（KILO_API_KEY、KILO_ORG_ID、BENCH_GITHUB_TOKEN），先检出私有仓库Kilo-Org/kilo-bench，再用uv sync --no-dev安装依赖。两个任务通过./scripts/run_eval.sh运行：

hello-world：数据集hello-world，模型kilo/anthropic/claude-sonnet-4.6；
log-summary-date-ranges：数据集terminal-bench-sample并--include-task-name指定任务名，同样模型。

工作流为--timeout-multiplier 2预留了 agent 安装阶段的镜像/CDN 慢速余量，随后用python3 scripts/validate_smoke_test.py jobs/smoke-test-*/校验结果，并上传result.json、trajectory.json与 agent setup 日志，保留 30 天。注释中的成本预算（hello-world 约 $0.01、log-summary 约 $0.13、总预算 < $0.50 且 < 15 分钟）也印证了这是"轻量冒烟"定位。

6.3 云 model-eval-ingest 证据与拟议评估设计

文档声明静态源码检查发现了云侧model-eval-ingest服务用于推广同步，仅视为"当前仓库定义的面"，部署环境与运行行为需另行验证后才能做生产声明。

更广泛的评测设计建议在实现期间验证适配器可用性后复用开源组件：Harbor（评测框架与数据集）、ATIF（结构化轨迹）、Opik（轨迹摄取与分析）、Terminal-Bench 或其他数据集。潜在架构：

Evaluation task set -> controlled trial environment -> verified Kilo adapter -> model request -> result and optional trajectory artifacts -> smoke validation, aggregate analysis, or trace analysis

拟议对比维度包括：模型对比（固定 Kilo Code agent 与任务集，变模型，测完成率/成本/墙钟时间）、agent 对比（固定模型与任务集，变 agent 或 Kilo Code 版本）、轨迹分析（固定评估任务，分析工具选择、错误与重复步骤）。

6.4 命令验证要求与未来交付物

文档特别强调：在适配器与自主 CLI 调用于相关仓库得到验证之前，不得把opik harbor run -a kilo、kilo --auto或kilo run --auto文档化为可用接口；私有 kilo-bench 工作流命令是实现证据而非公开使用保证。未来交付物包括：验证并文档化受支持的自主 CLI 调用、验证 Harbor 适配器归属与可用性、定义 ATIF 导出字段与数据处理策略、在发布命令前验证 Opik 摄取路径、本地复现成功后再发布贡献者工作流、在成本与运行时间允许时把 smoke 覆盖扩展为稳定回归子集。

七、如何参与：复用提案模板提交新设计

若你希望在 Kilo Code 中提出新功能设计，可直接复用提案模板：先写 Status callout 并选定生命周期标签，然后依次填充 Overview、Requirements（含 Non-requirements）、Current implementation（Partial 专用）、Roadmap、System design、Scope and implementation（可拆分为 GitHub issues 的工作项）、Compliance considerations（安全/隐私/数据处理/SOC 2）与 Future work。模板中 Status 指引是强制性的——每个提案页都必须有可见状态标注，Partial页面还必须把已发布行为与暂定规划分表列出，这保证了 Kilo 的功能文档始终"可验证、不夸大"，也让贡献者、Agent 与 LLM 在检索这些页面时能准确区分"已实现"与"规划中"。

参考与延伸阅读

提案索引与状态登记：packages/kilo-docs/pages/contributing/features/index.md
提案模板与生命周期状态机：packages/kilo-docs/pages/contributing/features/template.md
四项提案正文：enterprise-mcp-controls.md、onboarding-improvements.md、agent-observability.md、benchmarking.md
smoke-eval 工作流源码：.github/workflows/smoke-test.yml
核心实现与测试证据目录：packages/core/src、packages/core/test

创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考