能落地的 Agent，
扛得住的数据平台。Agents that ship.
Data platforms that scale.

选 MySQL 队列：FOR UPDATE SKIP LOCKED 并发领取，Redis 做心跳与 GPU 限流，outbox 发事件。队列可查、可修，不会出现“消息发了、状态没写”的双写不一致。再把“执行完成 ≠ 交付完成”写成状态机：产物可读、版本落账、血缘闭合才算 READY。I kept it in MySQL: concurrent claiming with FOR UPDATE SKIP LOCKED, Redis for heartbeats and GPU throttling, an outbox for events. The queue stays queryable and repairable, with no dual-write gap between message and state. Then I made "executed ≠ delivered" a state machine: READY only when the artifact is readable, the version recorded and the lineage closed.

验收坚持故障注入，不只看吞吐：以“任务 + 文件”为幂等键，280 次重试只产出 1 个数据集版本。GPU 限流 3 Worker 并跑，Redis 采样 1,383 次仅 1 次瞬时越限。Acceptance required fault injection, not just throughput: with task + file as the idempotency key, 280 retries produced exactly one dataset version. Under GPU throttling with three workers, 1,383 Redis samples showed a single momentary overshoot.

采用对象存储原生 SDK 重签、浏览器直传。每个分片签一个 URL，直传到固定编号的 staging key；直传失败可按片回退到后端代理，两条路写同一个 key。complete 不信会话记录，直接列目录核对片数与总字节，缺片就拒。解压侧给每次 staging 写入包上应用层退避重试，把瞬断当成可重试。Re-sign with the object store's native SDK and upload straight from the browser. One presigned URL per part, written to a fixed, numbered staging key; a failed part can fall back to the proxy and both paths write the same key. Completion ignores session records and lists the prefix to check part count and total bytes, rejecting any gap. On extraction, every staging write gets application-level retry with backoff, so transient drops are retryable.

生产验收：约 10 GB 测试包，310 个分片，237 秒，41.8 MiB/s，零中断；故意缺一片（309/310）时服务端拒绝。30 GB 合成包 480/480 文件、内存峰值 1.5 GB。生产血缘事件回填 18,370 条，六类对账全等。真实 1 TiB 与完整故障组合未跑完，方案里如实写明。Production acceptance: a ~10 GB package, 310 parts, 237 s, 41.8 MiB/s, no interruptions; with one part deliberately missing (309/310) the server refused. A 30 GB synthetic package landed 480/480 files at 1.5 GB peak memory. Backfilling lineage in production produced 18,370 events, with all six reconciliations exact. A real 1 TiB run and the full fault matrix were not finished, and the design document says so.

选单机 k3s，把单点风险写进方案而不是回避；Argo CD 先 apply-only 分批纳管，设五条硬停止条件。定下“CI 是唯一出图口”，回滚就是改一行镜像 tag。事故后固化：改共享凭证时，一次性注入并重启依赖它的全部模块；验证用 11 × 7 = 77 格全矩阵而不抽样。Single-node k3s, with the single point of failure written into the plan rather than hidden; Argo CD apply-only in batches behind five hard stop conditions. CI became the only source of images, so a rollback is a one-line tag change. After an incident I set two rules: when a shared credential changes, inject it into and restart every module that depends on it in one go; and verify the full 11 × 7 = 77-cell matrix instead of sampling.

access log 从 1,313 万行降到 71.2 万行，告警有效覆盖 64/64。生产 15 天探针可用性 99.9975%，7 天 331 万真实请求；100 并发压测整体 p95 50 ms。在与生产同机同配置的预发环境做极限压测，定位 project 服务 CPU 打满，2 核扩到 6 核后 84 → 205 req/s，p95 2.6 s → 0.85 s。Access logs fell from 13.13 M to 0.712 M lines, with 64/64 effective alert coverage. In production: 99.9975% availability over a 15-day probe and 3.31 M real requests in 7 days; a 100-user load test ran at 50 ms p95. A stress test in pre-production, on the same host and configuration, found the project service CPU-bound; going from 2 to 6 cores took it from 84 to 205 req/s and p95 from 2.6 s to 0.85 s.

换 EfficientViT-SAM。三条理由：质量上 FastSAM 不是检测器，CLIP 只能重排；速度上 9.4 倍；许可证上 README 写 Apache、LICENSE 文件实为 AGPL，私有化分发会触发 copyleft。INT8 被否决：只快 1.7 倍，mask IoU 掉到 0.42，而模型自估 IoU 不变，坏了也察觉不到。命名也守纪律：CPU 版不借用 SAM 3 的名字，不做虚假能力声明。EfficientViT-SAM, for three reasons: quality, since FastSAM is not a detector and CLIP can only re-rank; speed, at 9.4×; and licensing, since the README says Apache but the LICENSE file is AGPL, so shipping it on-prem would trigger copyleft. INT8 was rejected: only 1.7× faster, mask IoU fell to 0.42 while the model's self-estimated IoU stayed the same, so failure would be invisible. Naming stays honest too: the CPU service does not borrow the SAM 3 name.

云上 4 核真机：6,000 ms → 640 ms；ORT 换 OpenVINO 后编码器 470 → 93 ms；线程数 2 → 4 为最优。另修一次 OOM：4K 图峰值内存 4,078 MB → 1,907 MB。On a real 4-core cloud VM: 6,000 ms → 640 ms; ORT to OpenVINO took the encoder from 470 to 93 ms; four threads was the sweet spot. A related OOM fix cut 4K-image peak memory from 4,078 MB to 1,907 MB.

冻结六个仓的基线 SHA，先在与客户同款 OS 的鲲鹏实机上真装。验证机 16 核全绿，到了客户现场的 32 核机器上，三个 Python 服务重启 60+ 次：OpenBLAS / OMP 按核数起线程，撞上 nproc 上限。于是给所有算力容器钉死线程数，并把“验证机与客户机同规格，核数也要对齐”写进规范。我的判断规则是：同类组件里只有一个配了某参数，往往是过去事故的遗迹，应推广到全部。Froze the baseline SHA of six repositories and did a real install on a Kunpeng machine running the customer's OS. The 16-core test machine was all green; on the customer's 32-core machine three Python services restarted 60+ times, because OpenBLAS / OMP start a thread per core and hit the nproc limit. So every compute container got pinned thread counts, and "the test machine matches the customer's, core count included" became a team rule. My rule of thumb: when only one of a family of components sets a parameter, it is usually the scar of an old incident, and should be applied to all of them.

两轮真装累计发现 19 个问题、5 个致命，例如 Docker 自身二进制是 x86、Redis 在 ARM64 上拒启、端口避让脚本把 9 个端口分到同一个。补丁复查时搭仿真环境真跑 21 条异常路径断言；验证脚本本身也被验证过。现场 5 条反馈逐一定性：1 条是真实缺陷，出补丁修复；其余主要是客户浏览器版本过低。Two real installs surfaced 19 issues, 5 of them fatal: the Docker binary itself was x86, Redis refused to start on ARM64, a port-avoidance script mapped nine ports to one. Patch review ran 21 failure-path assertions in a simulated environment, and the verification scripts were themselves verified. Five field reports were each triaged: one genuine defect, patched; the rest came mostly from an outdated customer browser.

逐项对照开源标杆后，优先规划并验收三个协作实现的 P0：确定性工作流、Agent 委派、MCP 标准。定位出多轮失败的头号原因是跨轮丢失工具可见性；缓存命中低的真凶是易变内容排在稳定段之前。工具目录 28 → 20，并加预算上限与打转检测。After a point-by-point review of leading open-source agents, I prioritized and validated three P0 enhancements implemented collaboratively: deterministic workflows, agent delegation and the MCP standard. The top cause of multi-turn failure was tool visibility lost between turns; low cache hit rates came from volatile content placed before stable sections. The tool catalog went from 28 to 20, with budget caps and loop detection.

输入 token 159 万 → 89.6 万，24 例回归失败 53 → 20，reflection 失败率 34.7% → 0。修复 MCP 服务注册指向过期 Pod IP 后，一个工具的平均耗时 72 s → 3.4 s。Input tokens 1.59 M → 0.896 M, regression failures across 24 cases 53 → 20, reflection failure rate 34.7% → 0. Fixing an MCP registration that pointed at a stale Pod IP took one tool's average latency from 72 s to 3.4 s.