Atlas 这类“通过自建 Agent 为创业公司运营提供可观测性（observability）”的项目，把 AI Agent 从聊天助手推向了运维自动化。可观测性在创业团队里长期是个尴尬话题：业务增长快、人员少、基础设施变化频繁，传统监控体系要么太重，要么配置成本高于实际收益。Atlas 的思路是让 Agent 自己判断要观测什么、自己去接数据源、自己生成监控项和仪表盘，并在运行过程中不断修正。本文不从产品官网复述功能，而是从工程实现角度拆解这类系统的设计难点：核心循环怎么设计、最小实现怎么写、验证机制为什么比生成能力更重要、上线后有哪些排错路径。读者如果正在做 AI Agent 应用，或者想用 LLM 减轻可观测性建设负担，这篇内容都可以直接对照落地。
1. 先理清：创业公司运营观测缺的不是工具，而是“搭观测的人”
1.1 创业公司运维观测的真实痛点
创业公司的后端团队通常只有一个名号，实际上每个人都要兼顾业务开发、发布、线上问题处理和值班。可观测性建设的真实痛点不是“没有 Prometheus”或者“没有 Grafana”，而是没有人能把监控体系搭起来并持续维护。
业务上线前需要回答几个问题：核心链路是哪几条，哪些指标真正反映业务健康，告警阈值定多少，仪表盘放哪几个面板。这些问题在成熟公司由 SRE 团队负责，在创业公司往往被无限搁置。结果是线上出了故障靠用户反馈，或者靠某位开发顺手打开数据库看一眼。
Atlas 这类系统想解决的，正是“搭观测的人”缺失的问题。它把监控项定义、SQL 查询生成、仪表盘编排、告警规则配置这些原本需要人工完成的资产建设任务，交给 Agent 自动生成。
1.2 传统可观测性链路为什么覆盖不了运营场景
传统可观测性链路可以拆成五层：采集器、存储、查询、展示、告警。每一层都有成熟开源方案，但把它们串起来需要大量人工配置。
以最常见的组合 Prometheus + Grafana 为例：
| 环节 | 需要人工做的事 | 创业团队常见结果 |
|---|---|---|
| 采集 | 部署 exporter，编写抓取配置 | 只采集了 CPU、内存等基础指标 |
| 存储 | 配置留存周期、容量规划 | 指标存几天就过期 |
| 查询 | 编写 PromQL 计算业务指标 | 业务指标没有人写 |
| 展示 | 设计仪表盘、维护图表 | 默认模板凑合用 |
| 告警 | 编写规则、配置通知渠道 | 告警规则严重缺失或噪音大 |
这套链路适合基础设施监控，但创业公司更关心的是“今天订单失败率为什么升高”“新用户注册转化是不是在下降”。这些运营类指标往往存在业务数据库里，需要写 SQL 去统计，而不是靠基础设施指标反映。
传统工具链没有自动把业务表和运营目标变成监控资产的能力，所以即使部署了整套监控平台，运营观测仍然空白。
1.3 “自建 Agent”到底自建了什么
“Self-building agents”直译是自我构建的 Agent，容易误解成 Agent 会无限地修改自己的代码或系统权限。实际在 Atlas 这类场景里，它自建的对象是观测资产，而不是 Agent 自身。
所谓观测资产，包括以下几类：
- 监控检查项：一段可执行查询和判定规则，例如“一小时内订单失败率超过 5%”。
- 仪表盘面板：把多个查询结果组织成可视化视图。
- 告警规则：阈值、时间窗口、通知渠道的组合。
- 数据源连接：从某个数据库或 API 拉取数据的能力。
自建的含义是：给定一个运营目标，Agent 根据当前数据结构、已有资产和运行状态，自动生成上述资产，而不是从预置模板里挑选。模板只能覆盖已知场景，自建 Agent 理论上能覆盖业务快速变化时不断出现的新场景。
这里要特别区分两个概念。Atlas 做的不是自动修复（auto-remediation），也就是不直接去改代码、重启服务或者回滚发布。它做的是自动建立观测能力，把“可观测”这一步自动化。实际要不要修复、怎么修复，仍然由人决策。
2. Atlas 这类系统把 Agent 循环拆成了四个阶段
2.1 核心循环：感知、规划、构建、验证
要让 Agent 自动生成可用的监控资产，不能只靠一次 LLM 调用。真实环境里，Agent 必须理解当前系统状态，才能生成正确的查询和规则。整个循环可以拆成四步：
- 感知（Perceive）：读取数据库结构、已有资产列表、历史运行结果，形成当前上下文。
- 规划（Plan）：根据用户目标和上下文，决定要构建哪些资产，拆成步骤。
- 构建（Build）：执行规划中的每个步骤，生成 SQL、仪表盘 JSON、告警规则。
- 验证（Verify）：对生成结果做语法校验、试运行、结果合理性判断，通过后才激活。
四步构成闭环。验证失败时，失败信息会反馈给 Agent，让它重新规划或修改查询。这个“生成后必须验证”的循环，是自建 Agent 和普通代码生成工具的核心区别。
普通代码生成模型只负责输出一段看起来合理的代码，而观测系统里的生成结果会立即影响线上监控质量。一条错误的 SQL 可能让仪表盘永远空白，一条错误告警规则可能让团队在凌晨反复被误报叫醒。所以验证阶段不是可选项，而是整个系统可靠性的支柱。
2.2 系统分层与模块职责
从工程结构看，一个 Atlas 风格系统可以拆成四层：
| 层 | 职责 | 关键组件 |
|---|---|---|
| 连接层 | 管理数据源、执行查询、读取 schema | 数据库连接池、只读账号、超时控制 |
| Agent 核心层 | 上下文组装、规划、调用 LLM、解析输出 | Prompt 模板、工具定义、步骤执行器 |
| 验证层 | 校验语法、试运行、结果合理性检查 | SQL 校验器、查询执行器、规则引擎 |
| 资产层 | 存储资产管理、状态流转、审计 | 配置库、审批接口、版本记录 |
这四层各司其职。连接层负责安全和性能，Agent 核心层负责决策，验证层负责质量把关，资产层负责让生成结果变成持久化配置。
实践中很容易犯的错误是把 Agent 逻辑和资产存储混在一起。Agent 生成结果后直接写进生产配置，没有中间态，后续想回滚或者审计就很难。正确的做法是 Agent 只输出资产定义，由资产层统一处理状态流转和持久化。
2.3 为什么“生成监控项”比“生成文本”难得多
很多人会问：LLM 连代码都能生成，生成一条监控 SQL 有什么难？难在三个地方。
第一是上下文完整性。生成一条正确 SQL 必须知道表名、字段名、字段类型、数据量级、时间字段格式。Agent 如果拿不到完整 schema，或者 schema 与实际库不一致，生成结果大概率不可用。
第二是正确性验证。代码生成可以靠编译或单元测试验证，监控 SQL 的验证要复杂得多。基础语法正确不代表逻辑正确，字段存在不代表口径正确，一条能跑出结果的查询也可能统计错了业务含义。
第三是环境约束。生产环境的数据库查询有超时、有并发限制、有敏感数据访问控制。Agent 生成的查询不能影响线上业务，这要求验证层在受限环境下执行试运行，而不是直接连生产库跑。
理解这三点，就能明白为什么这类系统要把大量工程投入放在“上下文收集”和“验证层”上，而不是单纯优化 Prompt 让它生成得更漂亮。
3. 用一个最小 Python 实现跑通“自建监控检查项”
3.1 环境准备与目录结构
下面用一个最小 Python 实现演示核心循环。示例只做学习用，不接入真实 LLM 时可以先用规则函数模拟 Agent 输出，跑通流程后再接 OpenAI 兼容接口。
环境要求：
| 项目 | 推荐值 | 说明 |
|---|---|---|
| Python | 3.10 以上 | 使用 dataclass、类型注解 |
| 数据库 | SQLite | 本地无依赖，适合演示 |
| LLM SDK | openai 或兼容 SDK | 也可以用 mock 函数替代 |
| 依赖管理 | pip + venv | 保持环境干净 |
目录结构按模块拆分，方便后面扩展：
atlas-demo/ ├── core.py # 资产模型与状态流转 ├── agent.py # Agent 主循环 ├── validate.py # 验证层 ├── store.py # 资产存储 ├── data/ │ └── demo.db # 本地测试数据库 └── config.yaml # Agent 配置先创建虚拟环境并安装依赖：
python3 -m venv .venv source .venv/bin/activate pip install openai pyyaml如果只是跑流程验证，不调用真实模型，可以跳过 openai 安装，用 mock 函数代替。
3.2 数据模型：用 ObservedAsset 表达 Agent 产出的资产
任何 Agent 生成结果在进入生产前都应该有一个明确的中间状态。这里定义 ObservedAsset 作为统一资产模型：
# core.py from dataclasses import dataclass, field from typing import Any import time @dataclass class ObservedAsset: asset_type: str # check | dashboard | alert_rule name: str definition: dict status: str = "draft" # draft -> validated -> active created_at: float = field(default_factory=time.time) updated_at: float = field(default_factory=time.time) def to_dict(self) -> dict: return { "asset_type": self.asset_type, "name": self.name, "definition": self.definition, "status": self.status, "created_at": self.created_at, "updated_at": self.updated_at, }状态流转固定为 draft -> validated -> active。任何新生成资产必须先进入 draft，验证通过才变成 validated，最后通过审批或自动策略才 active。这个模型避免 Agent 生成结果直接生效的风险。
3.3 实现 Agent 主循环
Agent 主循环按感知、规划、构建、验证四步组织。这里用一个可替换的 llm_client 参数，便于接 mock 或真实模型。
# agent.py import json import sqlite3 import time from core import ObservedAsset from validate import validate_check class AtlasAgent: def __init__(self, db_path: str, llm_client, store: dict): self.db_path = db_path self.llm = llm_client self.store = store # name -> ObservedAsset self.max_steps = 5 self.max_build_attempts = 2 def collect_context(self) -> dict: """感知阶段：读取 schema 和已有资产""" conn = sqlite3.connect(self.db_path) cur = conn.cursor() cur.execute("SELECT name FROM sqlite_master WHERE type='table'") tables = cur.fetchall() schema_ctx = {} for (table,) in tables: cur.execute(f"PRAGMA table_info({table})") schema_ctx[table] = [row[1] for row in cur.fetchall()] conn.close() return { "schema": schema_ctx, "existing_assets": list(self.store.keys()), } def plan(self, goal: str, context: dict) -> list: prompt = self._build_plan_prompt(goal, context) response = self.llm.plan(prompt) return json.loads(response)["steps"] def run(self, goal: str): context = self.collect_context() steps = self.plan(goal, context) created = [] for step in steps[: self.max_steps]: if step["kind"] == "build_check": asset = self._build_check(step, context) if asset is not None: created.append(asset) return created def _build_check(self, step: dict, context: dict): """构建阶段：生成 SQL 并保存 draft 资产""" definition = { "metric": step["metric"], "query": step["query"], "threshold": step.get("threshold", 0.0), "window": step.get("window", "1 hour"), } asset = ObservedAsset( asset_type="check", name=step["name"], definition=definition, ) self.store[asset.name] = asset return assetAgent 循环里最要紧的是把每一步结果落进 store，而不是临时变量。这样后续验证、审批、追溯都有依据。
3.4 让 Agent 生成一个订单健康检查
先用规则函数模拟 LLM，验证整个流程：
# mock_llm.py def mock_plan(prompt: str) -> str: return json.dumps({ "steps": [ { "kind": "build_check", "name": "one_hour_order_failure", "metric": "order_failure_rate", "query": ( "SELECT " " SUM(CASE WHEN status='failed' THEN 1 ELSE 0 END) * 1.0 / COUNT(*) " "FROM orders " "WHERE created_at >= datetime('now', '-1 hour')" ), "threshold": 0.05, "window": "1 hour", } ] })真实接入时，plan prompt 需要把 schema 和已有资产列表完整注入。mock 能帮助先跑通状态流转，再逐步替换成真实模型。
用 demo 数据执行：
# run_demo.py import sqlite3 from agent import AtlasAgent from mock_llm import mock_plan conn = sqlite3.connect("data/demo.db") conn.execute( "CREATE TABLE IF NOT EXISTS orders (" "id INTEGER PRIMARY KEY, status TEXT, created_at TEXT)" ) conn.execute("INSERT INTO orders VALUES (1, 'success', datetime('now', '-30 minutes'))") conn.execute("INSERT INTO orders VALUES (2, 'failed', datetime('now', '-30 minutes'))") conn.commit() conn.close() agent = AtlasAgent("data/demo.db", llm_client=mock_llm, store={}) created = agent.run("监控订单健康度，重点看一小时内失败率") for asset in created: print(asset.to_dict())运行后会看到 Agent 生成一个名为 one_hour_order_failure 的检查项，状态是 draft。这个流程体现了一个重要设计：Agent 只负责生成，不负责上线。
4. 几个关键设计决策：权限、验证、成本、审批
4.1 权限边界：Agent 只能写配置，不能直接动数据
Agent 需要连接数据库读取 schema 和试运行查询，但它不应该拥有写入权限。设计上要遵守两条边界：
第一，Agent 使用的数据库账号必须是只读账号。即使 Agent 生成了错误的 DELETE 或 UPDATE，也会被执行层直接拒绝。SQLite 场景可以在连接层检查语句前缀，生产数据库应该在账号权限层就限制。
第二，Agent 能修改的只有可观测性配置，即检查项、仪表盘、告警规则，不能直接修改业务表、不能执行 DDL、不能改权限配置。配置变更走资产层统一接口，不做直接写入。
# validate.py 中的只读检查示例 def ensure_read_only(sql: str): normalized = " ".join(sql.strip().lower().split()) allowed_prefixes = ("select", "with", "explain") if not any(normalized.startswith(p) for p in allowed_prefixes): raise ValueError(f"query must be read-only, got: {sql[:80]}")只读检查是最后一道兜底，真正的安全边界还是要靠数据库账号权限。应用层检查能拦截失误，不能替代底层的权限控制。
4.2 验证机制比生成能力更值得投入
Agent 生成能力再强，如果验证机制薄弱，用户就无法信任输出结果。一个完整的验证层至少包含四道检查：
| 检查项 | 作用 | 失败处理 |
|---|---|---|
| 语法校验 | 确认 SQL 可以被解析 | 丢弃并重新生成 |
| 只读校验 | 防止写入和 DDL | 直接拒绝 |
| 试运行 | 确认查询能执行 | 返回错误信息给 Agent |
| 结果合理性 | 确认字段类型、行数、数值范围合理 | 标为待人工确认 |
# validate.py import sqlite3 def validate_check(asset, db_path: str, timeout: int = 5) -> dict: query = asset.definition["query"] try: ensure_read_only(query) except ValueError as e: return {"ok": False, "error": str(e)} conn = sqlite3.connect(db_path) conn.execute(f"PRAGMA query_only = ON") try: cur = conn.cursor() cur.execute(query) columns = [d[0] for d in cur.description] if cur.description else [] rows = cur.fetchmany(5) return {"ok": True, "columns": columns, "sample_rows": rows} except Exception as e: return {"ok": False, "error": repr(e)} finally: conn.close()试运行结果非常关键。字段是否存在、查询是否超时、返回的数据是否为空，这些信息都应该回传给 Agent，作为下一轮生成或修改的依据。如果 Agent 第一次生成的查询字段名错误，验证层能把具体错误字符串注入上下文，让它修正。
4.3 成本控制：把步数和重试次数变成显式参数
调用 LLM 有成本，Agent 循环如果失控，一次任务可能产生几十次模型调用。把成本相关参数显式放到配置里：
# config.yaml agent: llm: model: gpt-4o-mini temperature: 0.2 max_tokens: 2000 limits: max_steps_per_run: 5 max_build_attempts: 2 validate_timeout_seconds: 10 guards: read_only: true require_approval: true allowed_asset_types: [check, dashboard, alert_rule]参数含义和影响：
| 参数 | 默认建议 | 调大的影响 | 调小的风险 |
|---|---|---|---|
| max_steps_per_run | 5 | 单次任务可覆盖更多资产，成本上升 | 复杂目标可能完不成 |
| max_build_attempts | 2 | 修复失败的几率更高 | 低质量结果直接进入人工处理 |
| temperature | 0.2 | 输出更随机 | 更适合代码生成，取低值 |
| validate_timeout_seconds | 10 | 复杂查询可跑完 | 超时导致误判失败 |
成本控制的原则是：宁可让 Agent 少干活，也不要让它无限重试。一次失败的生成返回给用户，比后台悄悄重试十次花掉大量 token 更可控。
4.4 审批流：draft -> validated -> active
生成结果要经过状态流转才能生效。推荐最简审批流：
- 所有 Agent 生成资产先进入 draft。
- 验证层通过后提升为 validated。
- 需要人工确认时，validated 状态等待审批。
- 审批通过后变为 active，才写入监控系统。
# store.py def approve(store: dict, name: str) -> dict: asset = store.get(name) if asset is None: raise KeyError(f"asset not found: {name}") if asset.status != "validated": raise ValueError("only validated asset can be approved") asset.status = "active" asset.updated_at = time.time() return asset.to_dict()对于信任度高的团队，也可以配置自动审批策略，但必须保留全量审计。人工审批的价值不在于拦截所有问题，而是让团队对 Agent 生成的内容保持知情。
注意：生成能力决定系统上限，验证和审批决定系统下限。实际落地时，应该先做厚验证层，再放开 Agent 的生成范围。
5. 运行验证：如何确认 Agent 生成的观测资产真的可用
5.1 启动本地环境
在 demo 目录执行：
python run_demo.py正常情况下会输出类似下面的结果：
{ "asset_type": "check", "name": "one_hour_order_failure", "definition": { "metric": "order_failure_rate", "query": "SELECT SUM(...) FROM orders WHERE ...", "threshold": 0.05, "window": "1 hour" }, "status": "draft", "created_at": 1741234567.89, "updated_at": 1741234567.89 }这个输出说明 Agent 完成了感知、规划、构建三阶段，产物是合理结构。接下来需要手动执行验证函数：
from agent import AtlasAgent from validate import validate_check agent = AtlasAgent("data/demo.db", llm_client=mock_llm, store={}) created = agent.run("监控订单健康度") asset = created[0] print(validate_check(asset, "data/demo.db"))5.2 三种验证方式
验证 Agent 生成的观测资产，至少做三层检查：
第一层是静态检查。确认 SQL 是否只读、字段是否存在、查询是否超时。这层自动化完成，不需要人工。
第二层是语义核对。把试运行返回的 sample_rows 和真实业务数据对比，确认统计口径正确。例如失败率的样本数据是 0.5，要人工确认“数据库中确实有一条 failed 订单和一条 success 订单”。
第三层是持续观察。Agent 生成的检查项在激活后，要持续跑一段时间，对比真实告警是否与业务故障吻合。这是最容易被忽略的部分。一个监控项生成出来，如果连续一周没有触发也没有业务事件，并不一定说明它正确，问题可能是阈值过高或查询条件写错导致永远返回 0。
5.3 预期输出与日志
为了让排查有据可依，每个阶段都要输出结构化日志。日志里至少包含：任务 ID、当前步骤、LLM 调用 token 数、验证结果、状态变化。
task_id=abc123 phase=perceive tables=orders size=2 schema_ok=true task_id=abc123 phase=plan steps=1 cost_tokens=320 task_id=abc123 phase=build asset=one_hour_order_failure status=draft task_id=abc123 phase=validate asset=one_hour_order_failure ok=true columns=[failure_rate] rows=1 task_id=abc123 phase=approve asset=one_hour_order_failure status=active日志的关键是让每个状态变化都能追溯。某条告警误报时，翻开日志就能看到这个告警规则是哪次任务生成、由谁审批、当时的 schema 是什么。
5.4 学习环境与生产环境差异
demo 跑通不等于可以上线。两类环境差异很大：
| 维度 | 学习/本地环境 | 生产环境 |
|---|---|---|
| 数据源 | SQLite 本地测试库 | 真实业务库只读账号 |
| 执行权限 | 应用层校验 | 数据库账号只读 + 网络隔离 |
| 审批 | 可跳过 | 必须，所有变更可回滚 |
| 存储 | JSON 文件 | 数据库 + 配置中心 |
| 审计 | 无 | 全量审计，包括 prompt 和输出 |
| 成本 | 可忽略 | 需要预算上限和告警 |
| 自身观测 | 无 | Agent 自身也要被监控 |
生产环境最需要额外补的是“对 Agent 的监控”。Agent 本身也是一个线上服务，它调用的数据源、生成频率、失败率、token 消耗都要有观测。如果监测系统本身由 Agent 生成，一旦 Agent 挂了，观测也会失效，所以要保留一套独立于 Agent 的基础监控。
6. 常见问题排查：从现象倒推根因
6.1 Agent 反复循环不收敛
现象是 Agent 不断生成新的检查项，或者反复重试同一个失败步骤，任务迟迟不结束。
常见原因有三个：上下文没有注入已有资产列表，导致重复创建同名检查项；验证失败信息没有完整回传给 LLM，导致 Agent 不知道错在哪；max_build_attempts 设置过大，给了 Agent 无限重试的空间。
检查方式先看日志中的 phase 分布。如果大量出现 plan 和 build，说明计划阶段没有收敛；如果大量出现 validate 失败，说明上下文信息不完整。处理方式是每次 plan 前把 store 中已有资产全量注入 prompt，同时把验证错误原样回传。例如字段不存在的错误字符串要完整放进下一轮生成上下文。
6.2 生成查询引用了不存在的字段
现象是 SQL 能通过语法检查，但试运行报 no such column。
根因往往是 Agent 拿到的 schema 与真实库不一致。可能原因有：schema 提取时机太早，表结构后来变了；使用了缓存 schema；多个数据源时把 A 库的表结构当作 B 库的上下文使用。
排查路径：先确认查询属于哪个数据源，再对比该数据源当前 schema。关键手段是让感知阶段每次运行都重新提取 schema，不缓存超过设定时长的 schema 信息。生产环境可以用 information_schema 或 PRAGMA 实时获取。
6.3 告警不触发或者频繁误报
告警不触发的原因包括阈值设置过高、时间窗口使用了固定时间而不是相对时间、查询结果一直为空。频繁误报则相反，阈值过低，或者统计口径把正常波动也算成了异常。
排查顺序应该是：先看查询结果是否正常，再确认阈值口径，最后看时间窗口定义。很多问题出在时间表达式上，例如用了 "2025-01-01 00:00:00" 这样的硬编码时间，而不是 datetime('now', '-1 hour')。对仪表盘和告警系统来说，时间窗口必须使用相对时间。
6.4 排错速查表
| 问题现象 | 常见原因 | 检查方式 | 处理建议 |
|---|---|---|---|
| Agent 重复生成同类型监控项 | 上下文没有注入已有资产 | 查看日志中 existing_assets 字段 | plan prompt 中注入现有资产清单 |
| SQL 报字段不存在 | schema 与库不一致 | 对比日志中的 schema 和 DB 实际结构 | 每次 run 重新读取 schema |
| 仪表盘面板一直无数据 | 查询用了固定时间范围 | 检查 dashboard JSON 时间参数 | 改用相对时间变量 |
| 告警不触发 | 阈值过高或查询为空 | 试运行查询并人工核对结果 | 调低阈值并用历史数据回测 |
| 误报频繁 | 统计口径包含正常波动 | 核对 SQL 条件和业务语义 | 增加排除条件或调整窗口 |
| LLM 调用超时 | prompt 太长或并发过高 | 查看调用耗时和 token 数 | 拆分上下文，增加超时重试 |
| token 消耗超预算 | 步数或重试次数过大 | 监控 cost_tokens 和调用次数 | 限制 max_steps 和 max_build_attempts |
排错原则：先看输入和上下文，再看验证日志，最后才怀疑模型能力。多数问题出在上下文不完整，而不是 LLM 不会写 SQL。
7. 落地建议：把整套流程放进创业团队的真实节奏
7.1 先固定一个可观测域
不要一开始就让 Agent 覆盖全公司所有监控。建议先选一个业务域，例如订单系统、支付回调或者注册转化，数据源数量控制在一到两个，表结构相对稳定。
固定域的好处是上下文可控、验证标准清晰、问题定位容易。订单域的 check 生成正确后，再逐步扩展到用户域、营销域。Agent 每次扩展都叠加在已有资产基础上，避免一次性面对过于复杂的 schema 和多个数据源。
7.2 每次变更都必须可追溯
Agent 生成的资产要像代码变更一样管理。每条 check、每个 dashboard 都要记录：
- 生成时间、任务 ID、调用的模型。
- 输入的目标和上下文快照。
- 验证结果和测试数据。
- 审批人、生效时间。
审计存储要独立于 Agent 的资产存储，防止 Agent 异常时连审计记录也被修改。回滚能力同样重要，任何 active 状态的资产都应该能回滚到上一个 validated 版本。
7.3 不要让 Agent 无限重试
LLM 调用有成本，Agent 在循环中消耗的 token 会在账单上直接体现。落地时建议设置双重上限：
单任务是硬限制，比如 max_steps=5、max_build_attempts=2。全局是软限制，比如每小时最多执行 20 个任务，超出后排队并告警。成本监控本身应该独立，不能依赖 Agent 自己上报，因为 Agent 异常时可能连上报逻辑都失效。
7.4 上线前检查清单
- 数据源连接是否使用只读账号，权限是否按库最小化。
- 查询是否都有超时控制，试运行是否在独立环境执行。
- 生成的资产是否默认 draft 状态，是否有审批流程。
- 是否有全量审计日志，日志是否包含 prompt 快照和验证结果。
- 是否设置 token 预算上限和任务数上限。
- Agent 自身是否有独立监控，Agent 故障是否有兜底告警。
- 是否需要回滚机制，历史版本是否可恢复。
- 是否先限制在单一业务域，schema 变更后是否能自动感知。
这套清单本质上是在回答一个问题：当 AI 开始替团队做观测决策时，团队怎么保证它做得既安全又正确。回答清楚这个问题，Atlas 的“self-building”才会真正产生价值。
下一步最值得做的实验，是在本地库里放一份和线上结构一致的脱敏 schema，让 Agent 自动生成三类资产：检查项、仪表盘、告警规则。先跑通“生成 -> 验证 -> 审批 -> 激活”的完整链路，再逐步接入真实数据和真实模型。这条路比一开始就追求复杂架构更稳，也更接近创业团队实际需要的自动化节奏。
