AI 编程工具已经不只是编辑器里的补全插件。monday.com 将运行在 Amazon Bedrock 上的智能体称为“AI Teammates”，并把它们接入真实的软件交付流程。根据其内部生产数据，每月使用 AI 编程工具的 Builder 已从一年前约一半增长到九成，单个工程师的 PR 吞吐量提升超过 50%。更值得关注的不是工具覆盖率，而是团队正在用置信度评分逐步缩短从“生成代码”到“自主合并”的距离。
生产级智能体的核心不是生成，而是闭环
普通编码助手的任务通常止于输出代码。生产级智能体则必须完成一个可验证的工作闭环：读取任务上下文、定位代码、提出修改、运行检查、创建 PR，并根据评审和 CI 结果继续修正。
可以把这个闭环拆成四层：
- 模型层：由 Amazon Bedrock 提供模型访问、调用接口和基础安全边界。
- 工具层：把代码搜索、文件修改、测试、静态检查和 Git 操作暴露为受控工具。
- 工作流层：保存任务状态，限制执行步骤，处理失败、重试和人工接管。
- 治理层：记录提示词、工具调用、代码差异、测试结果和最终决策，形成可审计轨迹。
来源摘要没有披露 monday.com 的完整组件清单，因此这里的分层不是对其内部架构的复刻，而是一种可以落地的参考实现。关键原则是：模型负责提出行动，确定性系统负责执行限制和验证结果。不要让模型仅凭一句“测试已经通过”获得合并权限，CI 平台的实际退出码才是可信信号。
十年代码库需要的是改造接口，而不是重新开始
成熟代码库很少具备智能体喜欢的整齐边界。历史构建脚本、隐式依赖、超大测试集和不一致的模块约定，都会让同一个修改在本地、CI 与生产环境中表现不同。monday.com 强调对十年代码库进行 retrofit，这说明生产落地依赖工程接口改造，而不只是更换模型。
团队可以优先补齐几类机器可消费的接口：
- 为每个模块提供稳定的测试、检查和格式化命令。
- 将架构约束写入仓库，而不是只保存在资深工程师的记忆中。
- 让 CI 输出结构化结果，包括失败用例、覆盖率变化和风险标签。
- 限制智能体一次可修改的目录、文件数量和差异规模。
- 为生成代码与人工代码保留相同的评审、权限和回滚路径。
例如，不要让智能体猜测如何验证某个包，可以在仓库中提供统一入口：
#!/usr/bin/env bash
set -euo pipefail
python -m ruff check .
python -m pytest -q
python -m mypy src
将它保存为 scripts/verify.sh 并赋予执行权限：
chmod +x scripts/verify.sh
./scripts/verify.sh
这段脚本本身并不智能，但它把“修改是否满足最低质量要求”变成了稳定协议。智能体、开发者和 CI 可以执行同一个命令，减少环境与判断标准的漂移。
可以这样实践：Bedrock 调用与置信度合并门禁
下面是一个可运行并可继续改造的最小 Python 示例。它调用 Amazon Bedrock Runtime 的 Converse API，让模型评估 PR 证据，然后由本地策略决定是否允许自动合并。示例假设你已经配置 AWS 凭证，并有权调用所选模型；运行前需要把 BEDROCK_MODEL_ID 改成账户和区域中可用的模型 ID。
安装依赖：
python -m pip install --upgrade boto3
export AWS_REGION=us-east-1
export BEDROCK_MODEL_ID='replace-with-an-enabled-model-id'
创建 merge_gate.py：
import json
import os
import re
import boto3
region = os.getenv("AWS_REGION", "us-east-1")
model_id = os.environ["BEDROCK_MODEL_ID"]
client = boto3.client("bedrock-runtime", region_name=region)
pr_evidence = {
"changed_files": 3,
"lines_changed": 84,
"unit_tests": "passed",
"lint": "passed",
"type_check": "passed",
"security_scan": "passed",
"protected_paths_changed": False,
}
prompt = f"""
You are a software change risk assessor.
Evaluate this pull request evidence:
{json.dumps(pr_evidence, indent=2)}
Return JSON only with this schema:
{{"confidence": 0.0, "risk": "low|medium|high", "reason": "short explanation"}}
Confidence means confidence that the change is safe to merge.
Do not claim that a check passed unless it appears in the evidence.
"""
response = client.converse(
modelId=model_id,
messages=[{"role": "user", "content": [{"text": prompt}]}],
inferenceConfig={"temperature": 0, "maxTokens": 300},
)
text = response["output"]["message"]["content"][0]["text"]
match = re.search(r"\{.*\}", text, re.DOTALL)
if not match:
raise RuntimeError(f"Model returned no JSON object: {text}")
assessment = json.loads(match.group(0))
hard_checks_passed = all(
pr_evidence[name] == "passed"
for name in ("unit_tests", "lint", "type_check", "security_scan")
)
auto_merge = (
hard_checks_passed
and not pr_evidence["protected_paths_changed"]
and pr_evidence["lines_changed"] <= 100
and assessment["risk"] == "low"
and float(assessment["confidence"]) >= 0.95
)
print(json.dumps({"assessment": assessment, "auto_merge": auto_merge}, indent=2))
运行：
python merge_gate.py
这里有意采用“双重门禁”：模型置信度只是一个输入，测试、安全扫描、受保护路径和差异规模仍由确定性规则判断。即使模型返回 0.99，只要测试失败或修改触及受保护目录，系统也不能自动合并。
真实环境还应验证模型输出的 JSON Schema，设置调用超时和成本上限，并把模型版本、输入证据、评分结果及最终合并者写入审计日志。对于数据库迁移、鉴权、计费、基础设施和安全策略等高风险修改，应直接要求人工批准。
从辅助到自治，按风险校准权限
九成月度使用率和超过 50% 的人均 PR 吞吐量说明，AI 工具可以成为日常工程流程的一部分。但吞吐量不是唯一目标：PR 数量增加也可能带来评审压力、重复代码和维护成本。团队需要同步观察回滚率、缺陷逃逸率、评审时长、变更失败率和每个已合并任务的模型成本。
更稳妥的采用顺序是：
- 从生成测试、文档和小型修复开始，只允许智能体创建草稿 PR。
- 收集置信度与真实结果，检查高分变更是否确实拥有更低失败率。
- 仅对低风险目录、小差异和全量检查通过的修改开放自动合并。
- 定期重新校准阈值；模型、提示词或工具链变化后，旧评分不能直接沿用。
- 保留一键停用、人工接管、权限撤销和快速回滚能力。
AI Teammates 的真正门槛不是让模型写出更多代码，而是让组织能够解释：智能体读取了什么、执行了什么、为什么获得这项权限，以及出错后如何停止和恢复。只有当这些答案可以被日志、规则和生产数据验证时，置信度评分才可能成为通往有限自治的工程机制，而不是一个看似精确的数字。