Sea Limited 旗下有 Shopee、Garena、SeaMoney 三条业务线，工程师规模庞大，产品迭代节奏极快。CPO 近期公开表态：正在把 Codex 部署到各工程团队，推进 AI-native 的软件开发方式。这不是"试点几个小组写写 Copilot"，而是把 agentic coding 当作工程基础设施的一部分来建设。
背后的判断很明确——写代码这件事本身正在被重新定义。
Agentic 开发不是"更快的补全"
过去两年，大多数团队对 AI 编码的体验停留在 inline completion：敲半行注释，模型补全剩下的代码。这确实省了打字时间，但软件工程的核心瓶颈从来不是打字速度——是需求拆解、上下文理解、多文件协调、测试闭环。
Codex 这类 agentic 工具的区别在于：它接收一个任务描述，自己规划步骤，跨文件读写，跑测试，根据失败结果调整方案，最终交付一个可审查的 diff。人从"逐行编写者"变成"任务定义者 + 结果审查者"。
Sea 的 CPO 看到的正是这个角色迁移。东南亚市场的竞争节奏不允许团队在低价值环节上堆人力，而 agentic 工具恰好把低价值的执行层自动化了。
东南亚场景的特殊压力
Sea 选择全量推进而不是小规模试水，和东南亚市场的几个特征直接相关：
-
多语言多币种：Shopee 覆盖七个国家，每个站点有独立的支付、物流、合规逻辑。模板代码大量重复，但细节差异密集——这类工作对人类来说枯燥且易错，对 agent 来说恰好是"给定约束、批量生成"的最佳场景。
-
移动端优先：Garena 的游戏和 Shopee 的购物都以移动端为主，UI 层迭代频率极高。Agent 可以在设计师提供 spec 后直接生成组件代码和对应的测试用例。
-
工程师分布广：Sea 在新加坡、深圳、雅加达等地都有研发中心。Agentic 工具提供了一致的代码质量基线，减少跨地域协作中的风格不一致问题。
用 Codex CLI 跑一个真实任务
下面是一个可以直接在终端运行的示例，展示如何用 OpenAI Codex CLI 让 agent 完成一个跨文件的小任务。假设你有一个 Python 项目，需要给现有 API 端点加上请求频率限制（rate limiting）。
先确认环境：
# 安装 Codex CLI（需要 Node.js 18+）
npm install -g @openai/codex
# 设置 API Key
export OPENAI_API_KEY="sk-xxxxxxxxxxxxxxxx"
# 进入你的项目目录
cd ~/projects/my-flask-api
然后给 Codex 下达任务：
# 让 agent 自动完成：添加 rate limiting、创建中间件、更新路由、补测试
codex "给这个 Flask 项目加上基于 IP 的请求频率限制：每个 IP 每分钟最多 60 次请求。要求：1) 创建 rate_limit.py 中间件；2) 在 app.py 中注册到所有路由；3) 在 tests/test_rate_limit.py 中补上对应的单元测试；4) 返回 429 时响应体包含 retry_after 字段。"
Codex 会自动：
- 读取项目现有文件结构
- 生成
rate_limit.py中间件 - 修改
app.py注册中间件 - 创建
tests/test_rate_limit.py - 运行测试，如果失败则自行修复
- 最终输出一个完整的 diff 供你审查
审查后确认提交：
# 查看 agent 生成的变更
git diff
# 确认无误后提交
git add -A && git commit -m "feat: add IP-based rate limiting middleware"
如果你想在 CI 中自动触发 agent 处理特定标签的 issue，可以用 GitHub Action：
name: Codex Auto-Fix
on:
issues:
types: [labeled]
jobs:
auto-fix:
if: contains(github.event.issue.labels.*.name, 'codex-task')
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Run Codex
env:
OPENAI_API_KEY: ${{ secrets.OPENAI_API_KEY }}
run: |
npm install -g @openai/codex
codex "${{ github.event.issue.title }}. 详细描述：${{ github.event.issue.body }}"
- name: Create PR
uses: peter-evans/create-pull-request@v6
with:
commit-message: "auto: codex-generated fix for issue #${{ github.event.issue.number }}"
title: "Codex fix for #${{ github.event.issue.number }}"
body: "Automated change by Codex agent. Review before merge."
这个 workflow 让团队只需在 issue 上打 codex-task 标签，agent 就会自动拉代码、执行任务、提 PR。人只需要做最终审查。
从试点到全量：部署节奏的建议
Sea 的做法是直接全量推进，但大多数公司没有同样的工程规模和紧迫性。更稳妥的路径是：
第一步：选对任务类型。 不要让 agent 做架构决策或复杂业务逻辑设计。先从高重复、低歧义的任务切入——CRUD 端点补全、测试用例生成、日志格式统一、i18n 字段填充。这些任务上下文清晰、验收标准明确，agent 的成功率最高。
第二步：建立审查习惯。 Agent 生成的代码必须经过人类 diff review，和普通 PR 一样走 code review 流程。初期建议每条 agent PR 都双人审查，积累对 agent 输出模式的信任度后再逐步放宽。
第三步：固化 prompt 模板。 团队在使用过程中会发现某些任务描述方式特别有效。把这些 prompt 固化成内部模板，新成员直接复用，减少"和 agent 沟通不畅"的摩擦。
第四步：度量真实收益。 记录每个 agent 任务的：提交到合并耗时、首次通过率、审查发现的问题数。和同类型人工任务对比，数据会告诉你哪些环节值得继续加大 agent 比重。
需要正视的边界
Agentic 开发目前有几个明确的限制：
- 长上下文理解仍不稳定：超过 20 个文件的项目级重构，agent 容易丢失约束，生成不一致的修改。
- 安全敏感代码不适合全自动：支付密钥处理、权限校验等模块，agent 可以辅助生成初版，但必须由安全工程师逐行审查。
- 团队文化需要同步调整：如果审查者习惯"看大概没问题就合并"，agent 输出的隐蔽缺陷会比人工代码更难被发现。审查纪律反而要更严格。
Sea 的判断是这些边界在快速收窄，工具能力每个季度都有可感知的提升，所以现在全量部署是抢占学习曲线的优势。对大多数团队来说，不必复制这个节奏，但应该开始积累使用经验——因为"定义任务、审查结果"这个新工作模式，迟早会成为工程师的基本技能。