企业官网建设流程全解析

1. 从“ax”这个标题说起：一个被低估的运行时编排切口

第一次看到“ax”这个标题，我脑子里蹦出来的不是某个具体产品，而是一类问题的缩写。结合热搜词里的 agentic、orchestration、runtime、Kubernetes，我基本能判断出，这大概率是在讲一套面向智能体（Agent）场景的运行时编排方案，名字取了个极简的“ax”，像是“agent execution”或者“agent orchestration axis”的缩写。这类项目最近一年冒出来特别多，原因很简单：大模型能力上来了，但把模型真正跑成一个稳定、可观测、可扩展的生产系统，中间的坑比想象中多得多。

我过去两年一直在做云原生和 AI 基础设施的交叉地带，从最早的把模型塞进容器里跑，到后来用 Kubernetes 调度推理服务，再到最近折腾 agentic 工作流，踩过的坑能写一本小册子。所以看到“ax”这个标题，我第一反应不是去查它到底是谁家的项目，而是想把它当成一个典型样本，拆一拆一个 agentic runtime 在 Kubernetes 上到底该怎么设计、怎么落地、怎么排错。这篇文章就是基于这个思路展开的，适合两类人看：一类是已经在用 Kubernetes 跑服务、想往 agent 方向延伸的运维和平台工程师；另一类是刚接触 agentic 概念、想知道底层运行时到底在干什么的开发者。我会尽量把原理讲透，把操作步骤写细，把踩过的坑摊开来说。

先给个整体判断：agentic runtime 和传统微服务 runtime 最大的区别在于，它的执行单元不是无状态的请求-响应，而是带状态、带工具调用、带多轮决策的“任务”。这就导致调度、隔离、超时、重试、可观测性这些维度的设计逻辑全变了。Kubernetes 本身是为无状态和有状态服务设计的，直接拿来跑 agent 不是不行，但需要一层编排层去补足语义。ax 这类项目要解决的，就是这个“补足”的问题。

2. 核心概念拆解：agentic、orchestration、runtime 到底指什么

2.1 agentic 不是“更聪明的 API”，而是执行范式的切换

很多人第一次听到 agentic 这个词，会把它理解成“带函数调用的 LLM”。这个理解不算错，但太浅了。我习惯用一个类比：传统 API 像自动售货机，你投币、选商品、出货，流程固定；agentic 更像你雇了一个助理，你告诉他“帮我订一张明天去上海的票，预算 800 以内，靠窗”，他会自己拆解任务、查航班、比价、下单，中间可能还会回来问你“高铁行不行”。这个“自己拆解、自己决策、必要时回头确认”的过程，就是 agentic 的核心。

落到技术层面，agentic 系统通常包含几个要素：一个决策核心（通常是 LLM）、一组可调用的工具（搜索、数据库、代码执行、外部 API）、一个记忆或状态存储、以及一个控制循环（loop）。这个循环会反复执行“观察-思考-行动”的步骤，直到任务完成或触发终止条件。理解这一点很关键，因为它直接决定了 runtime 的设计：你不能假设一次调用就结束，你得为“长时间运行、多次交互、可能失败重试”做好准备。

2.2 orchestration 在 agent 场景下的特殊含义

Orchestration 这个词在云原生里一般指容器编排，Kubernetes 就是代表。但在 agentic 语境下，它多了一层含义：不只是编排容器，还要编排“决策流程”。我把它拆成三个层次来看。

第一层是基础设施编排，也就是把 agent 的各个组件（决策服务、工具服务、记忆存储）调度到合适的节点上，保证资源隔离和弹性伸缩。这一层 Kubernetes 很擅长，不用重新造轮子。

第二层是任务编排，指的是一个复杂任务如何拆成子任务、子任务之间如何传递上下文、失败后如何回滚或重试。这一层是 agentic runtime 真正要发力的地方，因为 Kubernetes 原生并不理解“任务”这个概念，它只理解 Pod 和 Job。

第三层是工具编排，也就是 agent 在运行过程中动态选择和调用工具。这一层往往和决策核心耦合在一起，但 runtime 需要提供工具注册、权限控制、调用审计的能力。

三层叠在一起，才是完整的 agentic orchestration。很多项目只做了第一层就宣称自己是 agent 平台，实际用起来会发现任务一复杂就乱套，根因就在这里。

2.3 runtime 是“执行环境”还是“执行协议”

Runtime 这个词被用得很泛。Java 有 JVM runtime，浏览器有 WebView2 runtime，容器有 container runtime。在 agentic 场景下，我更愿意把 runtime 理解成“执行协议 + 执行环境”的组合。协议部分定义了 agent 如何被启动、如何接收输入、如何上报状态、如何被终止；环境部分提供了它运行所需的依赖、隔离和资源。

为什么强调协议？因为 agent 的执行是长时的、有状态的，如果没有一套清晰的协议，编排层就不知道一个 agent 到底是“还在思考”还是“已经卡死”。我见过太多项目，agent 跑着跑着就挂在那里，日志里什么都没有，排查起来极其痛苦。根因就是 runtime 没有定义心跳和状态上报机制。

3. 为什么选 Kubernetes 作为底座：优势与需要补的课

3.1 Kubernetes 能直接给 agentic runtime 带来什么

先说优势，这部分是实打实的。Kubernetes 经过这么多年发展，在以下几个方面已经非常成熟，直接拿来用能省掉大量重复建设。

资源调度和隔离方面，Kubernetes 的 requests/limits、命名空间、NetworkPolicy、SecurityContext 这套组合拳，能保证不同 agent 任务之间互不干扰。尤其是当你的 agent 会执行代码或者访问敏感数据时，隔离不是可选项而是必选项。

弹性伸缩方面，HPA 和 Cluster Autoscaler 能根据负载自动调整副本数。Agent 任务的负载波动往往比传统服务更大，因为一个复杂任务可能瞬间拉起几十个工具调用，这时候弹性能力就体现出价值了。

可观测性方面，Kubernetes 生态里的 Prometheus、Grafana、OpenTelemetry 已经形成了事实标准。Agent 的运行指标、日志、链路追踪都可以接入这套体系，不用自己从头搭。

声明式管理方面，YAML 描述期望状态、控制器负责收敛，这个模式对于管理大量 agent 配置非常友好。你可以把 agent 的定义、工具清单、权限策略都写成 CRD，用 GitOps 的方式管理。

3.2 Kubernetes 原生能力覆盖不到的地方

但 Kubernetes 不是万能的，在 agentic 场景下它有几个明显的短板，这也是 ax 这类 runtime 存在的意义。

第一个短板是任务语义缺失。Kubernetes 的 Job 适合批处理，但 agent 任务往往是“长时运行 + 多次交互 + 可能中途改变目标”，Job 的完成语义对不上。你需要一层抽象把 agent 任务映射成 Kubernetes 资源，同时保留任务级别的状态管理。

第二个短板是状态管理薄弱。Agent 需要记忆，需要跨轮次保持上下文。Kubernetes 的 Pod 是无状态的（或者说状态需要外挂），你得自己接一个状态存储，并且处理好并发访问和一致性。

第三个短板是工具调用的动态性。Agent 在运行时才决定调用哪个工具，而 Kubernetes 的资源配置是静态的。你没法在 YAML 里预先声明“这个 agent 可能会调用搜索工具”，只能通过 sidecar 或者服务网格的方式动态注入。

第四个短板是超时和重试的粒度。Kubernetes 的 liveness/readiness probe 是给服务用的，agent 的“健康”定义完全不同。一个 agent 可能正在等一个慢速工具返回，这时候它不该被重启。你需要自定义健康判断逻辑。

3.3 一个务实的架构分层思路

基于上面的分析，我一般建议把 agentic runtime 分成四层来设计，从下往上依次是：基础设施层（Kubernetes）、运行时层（容器 + 状态存储 + 工具代理）、编排层（任务调度 + 流程控制）、应用层（具体 agent 逻辑）。ax 这类项目通常覆盖运行时层和编排层，把基础设施层交给 Kubernetes，把应用层留给业务开发者。

这个分层的好处是职责清晰。基础设施层的问题找平台团队，运行时层的问题找 runtime 维护者，应用层的问题找业务方。我见过一些团队把所有逻辑揉在一起，结果一个 agent 出问题，从内核参数查到 prompt 写法，效率极低。

4. 实操落地：从零搭一个最小可用的 agentic runtime

4.1 环境准备与前置检查

动手之前，先把环境确认清楚。我踩过的第一个坑就是版本不匹配，Kubernetes 版本、容器运行时版本、CRD 版本三者之间经常有兼容性问题。下面是我常用的检查清单。

# 确认 Kubernetes 版本，建议 1.26 及以上 kubectl version --short # 确认容器运行时正常，这一步经常出问题 kubectl get nodes -o wide crictl info # 确认 CRD 可以正常创建 kubectl api-resources | grep customresourcedefinition # 确认存储类可用，agent 状态需要持久化 kubectl get storageclass

这里重点说一个高频报错：container runtime is not running。这个错误通常出现在节点刚重启或者容器运行时配置被改动之后。排查顺序是：先看systemctl status containerd（或对应的运行时服务），再看/etc/containerd/config.toml里的配置有没有语法错误，最后看 kubelet 日志里有没有连接运行时的报错。我遇到过因为 cgroup 驱动不一致导致的这个问题，kubelet 用 systemd，containerd 用 cgroupfs，两边对不上，改一致就好了。

还有一个容易忽略的点是 WebView2 runtime 这类依赖。如果你的 agent 需要跑浏览器自动化或者渲染任务，容器镜像里得预装对应的 runtime，否则运行时会报could not find the webview2 runtime。这个错误在 Windows 容器里更常见，Linux 下一般是缺 Chromium 相关库。

4.2 定义 agent 任务的 CRD

Kubernetes 原生资源不够用，第一步是定义自己的 CRD。我设计了一个简化版的 AgentTask，字段不多但够用。

apiVersion: apiextensions.k8s.io/v1 kind: CustomResourceDefinition metadata: name: agenttasks.ax.example.com spec: group: ax.example.com versions: - name: v1alpha1 served: true storage: true schema: openAPIV3Schema: type: object properties: spec: type: object properties: goal: type: string maxSteps: type: integer default: 20 timeoutSeconds: type: integer default: 600 tools: type: array items: type: string memoryRef: type: string status: type: object properties: phase: type: string currentStep: type: integer lastHeartbeat: type: string scope: Namespaced names: plural: agenttasks singular: agenttask kind: AgentTask shortNames: - at

这里有几个设计决策值得说明。maxSteps是防止 agent 陷入死循环的硬性上限，我建议默认值不要设太大，20 步对于大多数任务够了，设太大反而会让卡死的任务占用资源更久。timeoutSeconds是任务级超时，和 Kubernetes 的 activeDeadlineSeconds 不同，它由 runtime 自己控制，因为 agent 的“超时”需要优雅处理，不能直接杀进程。memoryRef指向一个 ConfigMap 或 Secret，里面存的是记忆存储的连接信息，这样可以把敏感配置和任务定义分开。

status里的lastHeartbeat是我强烈建议加的字段。Agent 每隔几秒更新一次心跳，编排层通过对比当前时间和心跳时间来判断任务是否卡死。没有这个字段，你只能靠日志猜，效率差十倍。

4.3 编写控制器逻辑

CRD 定义好了，接下来是控制器。控制器负责监听 AgentTask 的创建，然后拉起对应的 Pod，并且持续同步状态。我用 Python 的 kopf 框架写一个骨架，逻辑清晰，适合快速验证。

import kopf import kubernetes import time @kopf.on.create('ax.example.com', 'v1alpha1', 'agenttasks') def create_fn(spec, name, namespace, logger, **kwargs): goal = spec.get('goal') max_steps = spec.get('maxSteps', 20) timeout = spec.get('timeoutSeconds', 600) logger.info(f"Creating agent task {name} with goal: {goal}") # 构造 Pod 定义 pod = kubernetes.client.V1Pod( metadata=kubernetes.client.V1ObjectMeta( name=f"agent-{name}", labels={"app": "ax-agent", "task": name} ), spec=kubernetes.client.V1PodSpec( containers=[ kubernetes.client.V1Container( name="agent", image="ax/agent-runtime:latest", env=[ kubernetes.client.V1EnvVar(name="GOAL", value=goal), kubernetes.client.V1EnvVar(name="MAX_STEPS", value=str(max_steps)), kubernetes.client.V1EnvVar(name="TIMEOUT", value=str(timeout)), ], resources=kubernetes.client.V1ResourceRequirements( requests={"cpu": "500m", "memory": "1Gi"}, limits={"cpu": "2", "memory": "4Gi"} ) ) ], restart_policy="Never" ) ) api = kubernetes.client.CoreV1Api() api.create_namespaced_pod(namespace=namespace, body=pod) return {"phase": "Running", "currentStep": 0}

这段代码里，restart_policy="Never"是个关键选择。Agent 任务失败后不应该被 Kubernetes 自动重启，因为重启意味着从头开始，而 agent 可能已经执行了一半有副作用的操作。正确的做法是让 runtime 决定是否重试，以及从哪一步重试。这一点和传统无状态服务完全不同，很多人在这里踩坑。

资源限制的设置也有讲究。Agent 的 CPU 消耗通常不高，但内存消耗可能很大，因为要维护上下文和记忆。我一般给 1Gi 起步，复杂任务给到 4Gi。如果 agent 会执行代码，还得考虑临时存储的限制，避免把节点磁盘写满。

4.4 状态存储与记忆管理

Agent 的记忆我一般分三层来存。短期记忆放在内存里，就是当前对话的上下文，任务结束就释放。中期记忆放在 Redis 里，跨轮次共享，设置合理的过期时间。长期记忆放在向量数据库里，用于检索增强，这个可以持久化。

Redis 的部署很简单，但有几个参数要调。maxmemory-policy建议设成allkeys-lru，避免内存打满。timeout设成 0，因为 agent 的连接可能是长连接。持久化用 AOF 而不是 RDB，因为 agent 的状态变化频繁，RDB 的快照间隔可能导致数据丢失。

向量数据库的选择要看规模。小规模用 pgvector 就够了，和 PostgreSQL 复用一套运维体系。大规模再考虑专门的向量库。我见过一些团队一上来就上重型向量库，结果运维成本比业务收益还高，不划算。

记忆的读写要注意并发。同一个 agent 任务可能有多个工具调用并行执行，它们都要读写记忆。我的做法是给每个任务分配一个独立的 key 前缀，然后用 Redis 的 WATCH/MULTI 做乐观锁。如果冲突频繁，再考虑换成更细粒度的锁。

5. 工具调用与安全隔离：agentic runtime 最容易出事的地方

5.1 工具注册与动态发现

Agent 的工具不能写死在代码里，得有一套注册机制。我的做法是用 ConfigMap 存工具清单，runtime 启动时加载，运行过程中可以热更新。

apiVersion: v1 kind: ConfigMap metadata: name: ax-tools data: tools.json: | { "tools": [ { "name": "web_search", "endpoint": "http://tool-search:8080/search", "timeout": 30, "retry": 2, "scopes": ["read"] }, { "name": "code_exec", "endpoint": "http://tool-exec:8080/run", "timeout": 120, "retry": 0, "scopes": ["execute"] } ] }

scopes字段是权限控制的关键。Agent 在调用工具前，runtime 会检查当前任务是否被授予了对应的 scope。这个检查必须在 runtime 层做，不能只靠工具服务自己判断，因为工具服务可能被绕过。我见过因为没做这层检查，agent 意外调用了删除数据的工具，后果很严重。

retry字段也要小心设置。查询类工具可以重试，执行类工具不能随便重试，因为可能有副作用。code_exec我设成 0 次重试，宁可失败让 agent 重新决策，也不要盲目重试导致重复执行。

5.2 网络隔离与出站控制

Agent 调用外部工具意味着有出站流量，这是安全风险的高发区。Kubernetes 的 NetworkPolicy 可以控制出站，但默认是全部放行的，你得显式收紧。

apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: ax-agent-egress spec: podSelector: matchLabels: app: ax-agent policyTypes: - Egress egress: - to: - podSelector: matchLabels: app: ax-tool ports: - protocol: TCP port: 8080 - to: - namespaceSelector: matchLabels: name: kube-system ports: - protocol: UDP port: 53

这段策略的意思是：agent 只能访问带app: ax-tool标签的 Pod 的 8080 端口，以及 kube-system 的 DNS。其他出站全部拒绝。这样即使 agent 被诱导去访问恶意地址，也会被网络层拦住。

实际部署时要注意，很多工具服务需要访问外部 API，这时候不能简单拒绝，而应该通过一个统一的出口代理，在代理层做审计和限流。出口代理的日志要保留，出问题时这是唯一的追溯依据。

5.3 资源配额与防滥用

Agent 的一个特点是可能“想太多”，反复调用工具，消耗大量资源。除了 maxSteps 限制，还得在资源层面做配额。

我一般给每个命名空间设置 ResourceQuota，限制总的 CPU、内存、Pod 数量。再给每个 agent 任务设置 LimitRange，防止单个任务申请过多资源。这两层配合，能有效防止一个失控的 agent 拖垮整个集群。

apiVersion: v1 kind: ResourceQuota metadata: name: ax-quota namespace: ax-agents spec: hard: requests.cpu: "20" requests.memory: "40Gi" limits.cpu: "40" limits.memory: "80Gi" pods: "50"

配额设置要留有余量，不能卡得太死。我一般按峰值负载的 1.5 倍来设，这样正常波动不会触发配额限制，真出问题时又能兜住。

6. 可观测性建设：让 agent 的“思考过程”可见

6.1 指标采集与关键指标定义

Agent 的指标和传统服务不一样，不能只看 QPS 和延迟。我关注的核心指标有这么几个。

任务成功率，指的是最终完成目标的任务占比。这个指标反映 agent 的整体能力，但要注意区分“任务本身无法完成”和“runtime 故障导致失败”，两者要分开统计。

平均步数，指的是完成任务平均需要多少轮决策。步数突然升高往往意味着模型能力下降或者工具出了问题。

工具调用失败率，按工具维度统计。某个工具失败率飙升，可能是它依赖的外部服务挂了。

心跳延迟，指的是任务上报心跳的间隔。延迟变大说明任务可能卡住或者资源不足。

这些指标通过 OpenTelemetry 采集，推到 Prometheus，再用 Grafana 做面板。我建议给每个指标都加上 task_id 和 agent_version 标签，方便下钻分析。

6.2 日志规范与链路追踪

Agent 的日志量很大，因为每一轮决策都要记录输入输出。如果不加规范，日志会变成一团乱麻。我的做法是结构化日志，每条日志都带 trace_id、task_id、step、event_type 字段。

import structlog logger = structlog.get_logger() logger.info( "agent_step", trace_id=trace_id, task_id=task_id, step=current_step, event_type="decision", thought=thought, action=action, duration_ms=duration )

链路追踪用 OpenTelemetry 的 span 来串。一个任务是一个 root span，每一轮决策是一个子 span，每次工具调用是一个更细的 span。这样在 Jaeger 里能看到完整的调用链，哪一步慢、哪一步失败一目了然。

这里有个坑要注意：agent 的上下文可能很长，如果把完整的 prompt 和 response 都塞进 span 属性里，会导致追踪系统存储爆炸。我的做法是只存摘要和哈希值，完整内容存到对象存储，通过 ID 关联。这样既保留了可追溯性，又控制了成本。

6.3 告警策略与误报控制

Agent 系统的告警很容易误报，因为它的行为本身就有随机性。同一个任务，这次成功下次可能失败，这不一定是故障。所以告警策略要设计得保守一些。

我一般设三条告警规则。第一条是任务成功率低于阈值，但要求连续多个时间窗口都低才触发，避免偶发波动。第二条是心跳超时，这个比较硬，超过预期时间没心跳基本就是卡死了。第三条是资源配额接近上限，这是预防性的，提前扩容比事后救火好。

告警的接收人要分清。Runtime 层面的告警发给平台团队，业务层面的告警发给业务方。我见过把所有告警都发给一个群的，结果大家都不看，真出事时没人响应。

7. 常见问题与排查技巧实录

7.1 任务卡死但没有任何报错

这是最常见也最头疼的问题。Agent 跑着跑着就不动了，日志停在某一步，没有异常。排查思路是这样的。

先看心跳。如果心跳还在更新，说明进程活着，可能是卡在某个工具调用上。去看工具服务的日志，确认请求有没有到达、有没有返回。如果心跳停了，说明进程可能挂了或者被 OOM kill 了，去看 Pod 的事件和节点的 dmesg。

再看资源。kubectl top pod看 CPU 和内存使用，如果内存接近 limit，很可能是 OOM。Agent 的内存泄漏往往来自上下文没有及时清理，每一轮都把历史全量拼进去，越拼越长。解决办法是设置上下文窗口上限，超出部分做摘要压缩。

最后看网络。如果 agent 在等一个永远不返回的 HTTP 请求，而客户端没有设超时，就会一直挂着。所有工具调用必须设超时，这是铁律。我一般设 30 秒，长任务设 120 秒，绝不设无限。

7.2 工具调用返回格式错误

Agent 依赖工具返回的结构化数据做决策，如果格式不对，agent 可能会解析失败或者做出错误决策。这类问题的根因往往是工具服务的版本升级导致 schema 变了，但 agent 侧的解析逻辑没跟上。

我的做法是在 runtime 层加一个 schema 校验，工具返回的数据先过校验再交给 agent。校验失败就返回一个标准错误，让 agent 知道这次调用失败了，可以重试或者换工具。这样比让 agent 拿到脏数据要好得多。

Schema 定义用 JSON Schema，放在 ConfigMap 里，和工具清单一起管理。工具升级时同步更新 schema，通过 CI 做兼容性检查，避免不兼容的变更上线。

7.3 并发任务互相干扰

多个 agent 任务同时跑的时候，可能会出现互相干扰。表现是任务 A 的数据出现在任务 B 的上下文里，或者任务 A 把任务 B 的资源占满了。

数据串扰一般是 key 冲突导致的。每个任务必须有独立的命名空间，Redis key、数据库表、临时文件路径都要带 task_id 前缀。我见过因为用了全局的临时目录，两个任务同时写同一个文件，结果数据混在一起。

资源争抢要靠配额和优先级解决。给重要任务设高优先级，用 PriorityClass 保证它们能优先调度。给普通任务设低优先级，资源紧张时可以被抢占。这样能保证关键业务不受影响。

7.4 常见问题速查表

这张表是我从实际故障里总结出来的，覆盖了八成以上的常见问题。遇到新问题先对照这张表，能快速缩小排查范围。

8. 性能调优与成本控制的一些实战心得

8.1 减少不必要的模型调用

Agent 的成本大头在模型调用上。每一轮决策都要调一次模型，步数越多成本越高。优化方向有两个：一是减少步数，二是降低单次调用成本。

减少步数靠更好的 prompt 和工具设计。把常用的工具组合封装成一个高层工具，agent 一次调用就能完成多个步骤。比如“查天气并推荐穿搭”可以封装成一个工具，而不是让 agent 先查天气再推理穿搭。

降低单次成本靠模型分级。简单决策用小模型，复杂推理用大模型。Runtime 可以根据任务类型动态选择模型。我实测下来，分级策略能省 40% 左右的成本，效果损失很小。

8.2 缓存与复用

Agent 的很多调用是可以缓存的。工具调用结果如果在一定时间内不变，可以缓存。模型调用如果输入相同，也可以缓存。缓存层用 Redis 做，key 是输入的哈希，value 是结果。

缓存要注意失效策略。工具结果缓存时间短一些，几分钟到几小时。模型结果缓存可以长一些，但要注意模型版本变化时清空缓存。我一般给缓存加一个版本前缀，模型升级时改前缀，旧缓存自然失效。

8.3 资源规格的持续调优

Agent 的资源需求不是固定的，会随着任务类型和负载变化。我建议定期 review 资源使用情况，根据实际数据调整 requests 和 limits。

调优的方法是看历史 P95 使用量，requests 设成 P50，limits 设成 P99 再加 20% 余量。这样既能保证大多数任务有足够资源，又不会浪费太多。Kubernetes 的 VPA 可以自动做这件事，但生产环境我建议先手动调几轮，摸清规律再上自动。

9. 后续可以扩展的方向

这套 runtime 跑通之后，还有几个方向可以继续深挖。一个是多 agent 协作，让多个 agent 分工完成复杂任务，这需要 runtime 支持 agent 之间的通信和协调。另一个是自适应编排，根据任务执行情况动态调整策略，比如发现某个工具经常失败就自动降级。还有一个是成本感知调度，在满足 SLA 的前提下优先选择便宜的资源。

我个人在实际操作中的体会是，agentic runtime 这个领域变化太快，今天的最佳实践明天可能就过时了。与其追求一步到位的完美架构，不如先把最小可用版本跑起来，在真实负载中发现问题、迭代改进。我见过太多团队花几个月设计“完美架构”，结果上线时发现需求已经变了。先跑起来，再优化，这个顺序不能反。

最后分享一个小技巧：给每个 agent 任务打上完整的标签，包括创建时间、任务类型、发起方、优先级。这些标签平时看着没用，出问题时是排查的关键线索。我吃过亏，早期没打标签，后来想按任务类型分析成功率，发现数据根本没法聚合，只能重新埋点。这个成本很低，收益很高，建议一开始就做。