开发者采用 AI 编程工具已经不是一个需要预测的趋势，而是正在发生的工作方式变化。Anaconda 于 7 月 15 日宣布收购 AI 工程 Agent 平台 Kilo Code。后者服务超过 300 万开发者，每月编排近 10 万亿 token。把这组规模数据和 Kilo Code CEO Scott Breitenother 的判断放在一起，收购逻辑就很清楚：企业很难阻止开发者使用 AI，但可以尝试管理模型、代码、数据与审计记录之间的交互。
从依赖治理延伸到 Agent 治理
传统开发治理围绕相对静态的对象展开，例如 Python 包版本、许可证、漏洞、制品来源和运行环境。AI Agent 改变了这个边界：它会读取仓库、生成代码、调用模型、执行工具，甚至在一次任务中消耗大量 token。
这使企业需要回答一组新的问题：
- 哪些仓库允许接入外部模型？
- 源代码、密钥和客户数据能否进入模型上下文？
- Agent 可以执行哪些 shell、Git 或部署操作？
- 谁发起了任务，使用了哪个模型，修改了哪些文件？
- 单次任务和团队每月可以消耗多少 token？
- 生成代码进入主分支前，需要通过哪些测试和审批？
从收购信息来看，Kilo Code 带来的是开发者入口和大规模 Agent 编排能力，Anaconda 则有机会把企业软件供应链管理经验延伸到 AI 开发流程。这里所谓的“治理层”，不应只是一个聊天界面上的权限开关，而应覆盖请求进入、工具执行、代码提交和事后审计的完整链路。
规模不是数字装饰，而是治理压力
每月近 10 万亿 token 意味着平台面对的不是零散的代码补全，而是持续、高频的模型调用。达到这种量级后，成本、安全与可观测性都会从团队问题升级为平台问题。
成本控制不能只看月末账单。平台需要记录调用者、仓库、模型、任务类型、输入输出 token 和失败重试，并允许按团队设置预算。否则，一次失控的循环调用或过宽的 Agent 任务就可能消耗大量资源。
安全控制也不能只依赖提示词。提示词可以表达意图，却不是可靠的权限边界。真正的控制点应位于模型网关和工具执行器：敏感仓库禁止调用未经批准的模型，部署命令需要人工确认，读取密钥目录应直接被运行时拒绝。
审计则要连接“模型请求”和“代码结果”。只记录使用了多少 token 不够，企业还需要知道某次提交是否由 Agent 参与、采用了什么策略、通过了哪些检查。与此同时，日志本身也可能包含源代码和提示词，因此需要脱敏、访问控制和保留期限。
可以这样实践：在 Agent 前增加策略检查
下面是一个概念性最小项目，用来演示治理层如何在 Agent 请求发出前检查模型、仓库级别和 token 预算。它不是 Anaconda 或 Kilo Code 的官方 API，但可以直接运行，也适合改造成内部模型网关的前置校验器。
创建 policy.yaml：
allowed_models:
- approved-code-model
- private-code-model
repository_rules:
public:
allow_external_model: true
internal:
allow_external_model: false
restricted:
allow_external_model: false
require_human_approval: true
limits:
max_tokens_per_request: 20000
创建 governance_check.py：
import json
import sys
from pathlib import Path
import yaml
def deny(reason: str) -> None:
print(json.dumps({"decision": "deny", "reason": reason}))
raise SystemExit(1)
def main() -> None:
if len(sys.argv) != 3:
raise SystemExit("usage: python governance_check.py policy.yaml request.json")
policy = yaml.safe_load(Path(sys.argv[1]).read_text())
request = json.loads(Path(sys.argv[2]).read_text())
model = request["model"]
repo_class = request["repository_class"]
requested_tokens = request["max_tokens"]
external_model = request.get("external_model", False)
approved = request.get("human_approved", False)
if model not in policy["allowed_models"]:
deny(f"model is not approved: {model}")
if requested_tokens > policy["limits"]["max_tokens_per_request"]:
deny("token limit exceeded")
rule = policy["repository_rules"].get(repo_class)
if rule is None:
deny(f"unknown repository class: {repo_class}")
if external_model and not rule.get("allow_external_model", False):
deny("external model is forbidden for this repository")
if rule.get("require_human_approval", False) and not approved:
deny("human approval is required")
print(json.dumps({"decision": "allow", "model": model}))
if __name__ == "__main__":
main()
再创建一个请求样例 request.json：
{
"actor": "developer@example.com",
"repository": "payments-service",
"repository_class": "restricted",
"model": "private-code-model",
"external_model": false,
"max_tokens": 8000,
"human_approved": true
}
安装依赖并执行检查：
python -m pip install pyyaml
python governance_check.py policy.yaml request.json
允许通过时，输出如下：
{"decision": "allow", "model": "private-code-model"}
在真实系统中，这个检查器应放在模型代理或任务调度器前，并进一步接入身份系统、密钥管理、不可篡改审计日志和预算服务。工具调用还要单独授权，不能因为模型请求获准，就默认允许 Agent 执行任意命令。
企业落地时应盯住四个边界
评估这类整合时，不应只比较模型数量或代码生成效果。更有价值的问题集中在四个边界：身份是否贯穿请求和提交，数据是否按仓库敏感级别流动，工具权限是否独立控制，审计记录是否足以还原一次 Agent 任务。
企业还要避免把治理做成阻塞开发的审批队列。低风险仓库可以自动放行，高风险操作再触发人工确认；常规补全与自主执行命令也应采用不同策略。治理越接近实际风险，开发者越不需要绕开平台。
Anaconda 收购 Kilo Code 的重要性，不只在于增加一个 AI 编程产品，而在于它把开发环境、软件供应链和 Agent 编排放进了同一个问题域。接下来真正值得观察的，是这套组合能否把治理能力做进开发工作流，同时保留开发者选择模型和工具的空间。