INTERVIEW INTRODUCTION · 05 MIN

冉熙Xi Ran 中国科学院大学 · 2027 届计算机技术硕士UCAS · M.S. Computer Technology, 2027

从业务 Agent 编排到云原生 Runtime，把模型能力做成可验证的系统。

From Agent orchestration to cloud-native runtimes, I turn model capabilities into verifiable systems.

University of Chinese Academy of Sciences

国科大杭高院 × 中科院计算所 × 浙江大学联合培养 Joint training across HIAS, ICT and Zhejiang University

Agent RuntimeSandbox · Warm Pool · Session

Agent OrchestrationTool Use · Routing · Recovery

工程验证Engineering ProofBenchmark · E2E · Open Source

冉熙在电脑前工作 — HANGZHOU · 2026AI AGENT ENGINEERING

面试官您好，我叫冉熙，是中国科学院大学计算机技术专业 2027 届硕士。我的定位是 Agent 系统工程：在 Bybit，我把专家排查拆成可编排、可恢复的 Agent 工具链；在华为，我进一步做到 Sandbox Runtime、性能验证和云原生上游交付。

Hello, I am Xi Ran, a 2027 master's candidate in Computer Technology at UCAS. I focus on Agent systems engineering: orchestrating recoverable toolchains for risk decisions at Bybit, then moving deeper into sandbox runtimes, performance validation and cloud-native upstream delivery at Huawei.

01 / TRAJECTORY

四段经历，一条 Agent 系统主线Four roles, one Agent systems trajectory

02

从应用交付，到 Agent 决策，再到 Agent Runtime：
负责的系统边界持续向下延伸。

From application delivery to Agent decisions and Agent runtimes, my ownership has moved deeper into the stack.

主线：业务问题 → Agent 编排 → Runtime 与上游Path: business problem → orchestration → runtime and upstream

2023.10–2024.06

趣链科技 · 企业应用研发Hyperchain · Enterprise Applications从业务需求到全栈交付Requirements to full-stack delivery

2025.06–2026.06

浙江大学 · 量化 Agent 系统Zhejiang University · Quant Agents多 Agent 决策与全栈平台Multi-Agent decisions and platform

2025.12–2026.06

Bybit · 风控 Agent 算法Bybit · Risk Agent Algorithms12 个 Tool 编排专家排查12 tools orchestrating expert analysis

2026.06–至今

华为 · Agent InfraHuawei · Agent InfraSandbox Runtime、Benchmark 与上游Sandbox runtime, benchmarks and upstream

10×Bybit Agent 提效Bybit Agent speedup

<1sSandbox 本地 p50local Sandbox p50

20华为实习相关上游合入 PRHuawei internship upstream PRs

我的主线不是换行业，而是逐步扩大 Agent 系统的责任边界：先交付完整应用，再负责 Agent 的工具编排和决策质量，最后深入 Sandbox Runtime、性能与云原生上游。下面我用两个 STAR 案例说明。

The trajectory is an expanding Agent systems boundary: complete applications, then tool orchestration and decision quality, and now sandbox runtimes, performance and cloud-native upstream work. The next two slides show concrete STAR cases.

02 / CASE STUDY · BYBIT

从 40 分钟人工流程，到 4 分钟全市场 AgentFrom a 40-minute manual flow to a 4-minute market-wide Agent

03

S / T：专家需要串行完成多轮取数、关联和验证，单币种耗时 20–40 分钟；我的任务是在查询资源受限的条件下实现可批量、可复核的 Agent 排查。

S / T: Experts spent 20–40 minutes per symbol on sequential retrieval, correlation and verification. I owned a batchable, reviewable Agent workflow under constrained query resources.

4 MIN端到端扫描全市场end-to-end, market-wide

10×人工流程提效workflow speedup

0→4同轮验证异常检出anomalies in one validation

Action：不是让模型直接给结论，而是把专家判断拆成有输入、阈值、失败处理和证据输出的工具链。

Action: The model never guessed the verdict directly; expert reasoning became tools with inputs, thresholds, failure handling and evidence.

01取数Retrieve6 SQL · Hive/Presto

02编排Orchestrate12 Tools · 5-way

03判定Decide交易多样性 · 8维评分diversity · 8D score

04恢复RecoverCDP · Checkpoint

05证据Evidence可解释报告reviewable report

约束：Constraint: 40GB 查询限制下用显式 UID、短路和分片规避 OOMexplicit UIDs, short-circuiting and sharding under a 40GB query limit

Result：Result: 累计识别 10+ 异常团伙，结论保留可复核证据10+ abnormal groups identified with reviewable evidence

背景是异常账户分散，专家要串行做多轮取数、聚类和行为验证，单币种需要二十到四十分钟，无法批量扩展。我的任务是在 Hive/Presto 查询资源受限的情况下，把这套判断变成可自动执行、失败可恢复、结论可复核的 Agent。我从零设计五阶段 Pipeline，开发六条协作 SQL 和十二个 Tool，使用五路并行与条件路由；算法上提出交易多样性信号并构建八维评分，工程上用显式 UID、短路、分片、CDP 自动恢复和断点续传处理 OOM 与长任务失败。最终把流程压缩到四分钟全市场扫描，实现十倍提效；同轮验证从零个异常提升到四个，累计识别十多个异常团伙。

Abnormal accounts were distributed, and experts spent 20–40 minutes per symbol on sequential retrieval, clustering and behavioral verification. I owned an automated, recoverable and reviewable Agent workflow under constrained Hive/Presto resources. I designed a five-stage pipeline with six SQL queries and twelve tools, using five-way parallelism and conditional routing. I added trade diversity and an eight-dimension score, plus explicit UID queries, short-circuiting, sharding, CDP recovery and checkpoints. The result was a four-minute market-wide scan, a 10x speedup, 0-to-4 anomalies in one validation, and more than ten groups identified cumulatively.

03 / AGENT INFRA · HUAWEI

把 Sandbox p50 从 7.315s 降到 436–565msReducing Sandbox p50 from 7.315s to 436–565ms

04

S / T：本地 k3s 的 10 并发 Agent Sandbox 请求出现明显排队；我要建立可复现 Benchmark，定位瓶颈并给出有边界的容量结论。

S / T: Ten concurrent Agent Sandbox requests queued heavily on local k3s. I built a reproducible benchmark to locate the bottleneck and produce a scoped capacity decision.

01 / MEASURE

Lifecycle

拆分 Create / Run / Delete，记录成功率、p50、p95 与控制面事件。Split Create / Run / Delete; record success, p50, p95 and control-plane events.

02 / DIAGNOSE

Pool Miss

对照 Pool 2 / 5 / 10 / 20，确认小池导致补池等待和长尾。Compare pools 2 / 5 / 10 / 20; isolate refill waits and tail latency.

03 / DECIDE

Capacity

Pool=10 消除主要排队；增至 20 反而回退，容量不是越大越好。Pool 10 removes major queuing; pool 20 regresses, so bigger is not always better.

HUAWEI · AGENT INFRA

Result（本地 k3s · 并发 10）：Result (local k3s · concurrency 10): p50 7.315s → 436/565ms · p95 804/933ms · 10/10 success

在华为的 Agent Infra 工作中，我遇到一个具体问题：本地 k3s 环境下，十个并发 Sandbox 请求在 warmPoolSize 等于二时 p50 达到 7.315 秒。我的任务不是调一个参数，而是先建立可复现、能解释生命周期开销的 Benchmark。我把请求拆成 create session、run code 和 delete session，记录成功率、p50、p95 与控制面事件，再对 Pool 2、5、10、20 做同环境对照。结果显示 Pool 10 的两轮 p50 降到 436 和 565 毫秒，p95 为 804 和 933 毫秒，十个请求全部成功；Pool 20 没有继续改善。这个案例让我形成了容量结论必须绑定环境、并发与命中率，而不能只报一个最好数字的方法。

In Huawei Agent Infra work, ten concurrent Sandbox requests on local k3s reached 7.315 seconds p50 with warmPoolSize two. My task was not merely tuning a parameter, but building a reproducible lifecycle benchmark. I separated create session, run code and delete session, recorded success, p50, p95 and control-plane events, then compared pools 2, 5, 10 and 20. Pool 10 reduced p50 to 436 and 565 milliseconds across two runs, with p95 at 804 and 933 milliseconds and all ten requests succeeding. Pool 20 did not improve further. The lesson is that capacity conclusions must stay tied to environment, concurrency and pool-hit conditions.

04 / UPSTREAM DELIVERY · AGENTCUBE

让 Agent Infra 代码真正进入上游Shipping Agent infrastructure into upstream

05

S / T

AgentCube PR #387 ↗agent-sandbox v0.4.6 · Warm Pool

上游 SandboxClaim 采用预热 Sandbox 后，Claim 名不再等于真实 Runtime；任务是兼容新对象关系，同时保留 direct 与 warm 两条路径。After SandboxClaim adopted a pre-warmed Sandbox, claim identity no longer matched runtime identity. The task was preserving both direct and warm paths.

18 FILES兼容边界compatibility scope

ACTION

Runtime identity ↗Go · Kubernetes · E2E

通过 Claim Status 找到 adopted Sandbox 与 Pod；控制面仍保存 Claim 身份用于 Delete/GC，并补齐 mTLS 基线与 focused Warm Pool E2E。Resolve the adopted Sandbox and Pod from Claim status, retain Claim identity for Delete/GC, and add mTLS baseline plus focused Warm Pool E2E.

12/12 CI目标链路真实执行target path executed

RESULT

Upstream delivery ↗AgentCube · Karmada · Work API

PR #387 合入 AgentCube；累计合入 AgentCube 11 个、Karmada 8 个、Kubernetes SIGs Work API 2 个 PR，覆盖 Sandbox、MCP、CI、多架构、调度与依赖升级。PR #387 merged; 11 AgentCube, 8 Karmada, and 2 Kubernetes SIGs Work API PRs now cover Sandbox, MCP, CI, multi-architecture, scheduling, and dependency upgrades.

21 PR已合入上游merged upstream

GitHub 官方状态截至 2026.09.04GitHub status observed 2026.09.04

第三个案例是把 Agent Infra 研究变成上游交付。Agent-sandbox v0.4.6 改变了 Warm Pool 的对象关系：Claim 会采用一个预热 Sandbox，所以控制身份和真实 Runtime 身份不再相同。我的任务是让 AgentCube 兼容新对象关系，又不破坏 direct path。实现上，我通过 Claim Status 解析 adopted Sandbox 和 Pod，用它连接 Runtime；同时继续保存 Claim 名用于 Delete 和 GC，并把默认 mTLS 基线与 focused non-mTLS Warm Pool E2E 分开验证，避免 CI 通过但目标用例实际未执行。PR #387 最终合入，官方 checks 12/12 通过；截至九月四日，我在 AgentCube 合入十一个、Karmada 八个、Kubernetes SIGs Work API 两个 PR，共二十一个上游 PR。

The third case is turning Agent Infra research into upstream delivery. Agent-sandbox v0.4.6 changed Warm Pool object relationships: a Claim adopts a pre-warmed Sandbox, separating control identity from runtime identity. I adapted AgentCube without breaking the direct path, resolving the adopted Sandbox and Pod from Claim status while retaining Claim identity for Delete and GC. I also separated the mTLS baseline from a focused non-mTLS Warm Pool E2E so passing CI could not silently skip the target. PR #387 merged with 12/12 official checks; by September 4 I had 11 AgentCube, eight Karmada, and two Kubernetes SIGs Work API PRs merged, 21 upstream PRs in total.

05 / ROLE FIT

目标岗位：Agent 系统工程师Target role: Agent Systems Engineer

06

我能负责一条 Agent 链路：编排、运行、验证、交付。

I can own an Agent system across orchestration, runtime, validation and delivery.

目标不是堆框架，而是让 Agent 在真实约束下可运行、可恢复、可测量，并最终进入产品或开源主线。

The goal is not framework accumulation, but Agents that run, recover and remain measurable under real constraints, then ship into products or upstream.

01

Agent Orchestration12 Tools · 条件路由 · 失败恢复12 tools · routing · recovery

02

Agent RuntimeSandbox · Warm Pool · 生命周期Sandbox · warm pool · lifecycle

03

Engineering ProofBenchmark · E2E · 18 个实习相关上游 PRBenchmarks · E2E · 18 internship upstream PRs

谢谢，期待交流。Thank you. I look forward to the conversation. [email protected] github.com/ranxi2001 ↗

因此我目标很明确：做 Agent 系统工程师。Bybit 证明我能把专家流程做成可编排、可恢复的 Agent；华为和 AgentCube 证明我能深入 Runtime、用 Benchmark 找瓶颈，并把代码通过 E2E 和 Review 送进上游。我希望继续对一条 Agent 系统从编排到运行和验证负责。谢谢。

My target is clear: Agent systems engineering. Bybit proves I can turn expert workflows into orchestrated, recoverable Agents; Huawei and AgentCube prove I can work in runtimes, diagnose bottlenecks with benchmarks, and ship through E2E and review. I want to own an Agent system from orchestration through runtime and validation.

APPENDIX / Q&A

能力地图：从底座到业务闭环Capability map: infrastructure to outcomes

A1

Agent Runtime

Go · Kubernetes · Sandbox
Warm Pool 2→10 · p50 7.315s→436/565msWarm Pool 2→10 · p50 7.315s→436/565ms

Agent Orchestration

12 Tools · 5-way Parallel
条件路由、CDP 恢复、断点续传Routing, CDP recovery and checkpoints

Data & Algorithms

6 SQL · 8D Score · 40GB
交易多样性、短路、OOM 规避Trade diversity, short-circuiting and OOM avoidance

Upstream Delivery

AgentCube 11 · Karmada 8 · Work API 2
兼容迁移、E2E、CI 与 Code ReviewCompatibility, E2E, CI and code review

这页用于追问时快速定位证据：Runtime 对应 Warm Pool Benchmark；Agent 编排对应 Bybit 的十二个 Tool；算法对应六条 SQL 与八维评分；华为实习上游交付对应 AgentCube 十一个、Karmada 八个与 Kubernetes SIGs Work API 两个已合入 PR。每一项都能继续展开到代码、测试或实验边界。

This appendix maps every capability to evidence: the Warm Pool benchmark for runtime, twelve Bybit tools for orchestration, six SQL queries and an eight-dimension score for algorithms, and 21 merged PRs across AgentCube, Karmada, and Kubernetes SIGs Work API for Huawei internship upstream delivery.

APPENDIX / OPEN-SOURCE PORTFOLIO

17 个上游仓库，按能力域完整展开17 upstream repositories, organized by capability

A2

17上游仓库repositories

60已合入 PRmerged PRs

19协作中 PRPRs in review

绿色：已合入 · 橙色：协作中Green: merged · Orange: in reviewGitHub 状态截至 2026.09.04Observed September 4, 2026

这页展示完整开源贡献版图，不计本人 fork、自有仓库或仅用于报名的 PR。17 个上游仓库按 Agent 与上下文、Runtime 与 Kubernetes、工具与社区三组展示；截至 2026 年 9 月 4 日，共 60 个 PR 已合入、19 个 PR 协作中。绿色只表示 GitHub merged 状态，橙色项目仍由 maintainer 决定后续是否合入。本页不是华为实习成果统计；华为实习范围仍以 AgentCube、Karmada 与 Kubernetes SIGs Work API 的 21 个已合入 PR 为准。

This appendix shows the full open-source portfolio, excluding personal forks, owned repositories, and registration-only PRs. Seventeen upstream repositories are grouped into Agents and Context, Runtime and Kubernetes, and Tools and Community. As of September 4, 2026, 60 PRs are merged and 19 remain in review. Green indicates GitHub merged status only; orange items still depend on maintainer decisions. This is not the Huawei internship outcome count, which remains 21 merged PRs across AgentCube, Karmada, and Kubernetes SIGs Work API.