哈喽，大家好，我是阿星
昨天去学习刘润年中大课发现企业家都在学codex👉🏻刘润年中大课笔记：一句话说清AI落地之战的本质
吓得我赶紧回来整理了这个手册😂
还是那句话，如果你现在只有空学一个AI工具，只学codex足够了。希望这个手册能替你省时间。
可以当教程看，也可以当手册查。
背景
很多人第一次听到 Codex，会下意识把它理解成“OpenAI 版的 Cursor”或者“另一个 AI 写代码工具”。这个理解不算错，但不够准确。今天的 Codex 已经不是一个单纯的代码生成器。
它更像一个能进入项目现场的 AI 编程 Agent：
可以读项目、改文件、运行命令、处理 Git、调用插件，也可以通过桌面端、命令行、IDE、Web、Chrome 扩展进入不同的工作流。
OpenAI 官方把 Codex 定义为面向软件开发的 coding agent，使用方面：ChatGPT Plus、Pro、Business、Edu、Enterprise 都包含 Codex 使用途径。(OpenAI Developers)
1.Codex 是什么？
一句话定义：
Codex 是 OpenAI 面向软件开发和工作自动化的 AI Agent。
普通 AI 编程工具更像“代码问答器”。你问它怎么写登录页，它给你一段代码；你复制到项目里，运行，报错，再回来问它怎么修。这个流程里，AI 只是给材料，真正执行的人还是你。
Codex 的方式不一样。你可以把一个真实项目目录交给它，让它先读项目，再按你的要求修改文件、运行命令、检查结果。比如你不只是说“帮我写一个登录页”，而是说：
请在当前项目中新增一个登录页面。
要求：
1. 复用现有 UI 组件；
2. 不引入新的表单库；
3. 支持邮箱和密码输入；
4. 增加基础校验；
5. 修改完成后运行类型检查；
6. 最后总结修改了哪些文件。
这就不是“生成代码片段”，而是“执行一个开发任务”。
Codex 的核心价值也在这里：它把 AI 编程从“问答式生成”，往“任务式执行”推进了一步。你不再只关心它会不会写某个函数，而是要学会给它定义目标、范围、限制和验收标准。
2.Codex 适合哪些人？
Codex 的第一批核心用户当然是程序员，但它不只适合程序员。只要你的工作里有项目、网页、表格、重复流程、小工具需求，它都可能有用。
程序员可以用它处理日常开发中那些不难但耗时间的事：读陌生代码库、补测试、修报错、拆组件、迁移旧接口、生成 PR 描述。
它最舒服的区间不是“从 0 做一个巨型系统”，而是有明确上下文的中等任务，比如“把当前列表页加一个搜索功能”“给这个模块补单元测试”“把这几个重复函数抽成工具方法”。
产品经理可以用它理解技术项目。比如你接手一个后台系统，不知道某个功能的数据从哪里来，可以让 Codex 解释页面、接口、状态管理之间的关系。它未必能替你做技术决策，但能让你和研发沟通时少一点“凭感觉猜”。
运营、自媒体人、培训老师也可以用。这里不用把自己想成程序员。你可以让 Codex 做一些轻量小工具，比如选题管理页面、课程资料整理器、评论关键词统计脚本、图片批量重命名工具、Excel 清洗脚本。
团队负责人可以用它做项目检查。比如总结最近一周改动，整理待 review 分支，分析哪些模块缺测试，或者把项目里的重复逻辑列出来。它不一定直接改代码，但可以帮你把信息先理出来。
所以，Codex 的使用门槛不在于“你是不是会写代码”，而在于你能不能把任务说清楚。
3.Codex 的主要入口怎么选？
Codex 不是一个单一入口，它现在更像一个产品家族。
新手不用一上来全学。先按自己的场景选。
我的建议很简单：如果你不知道选哪个，先装 Desktop。它是最容易理解的入口。你能看到项目、线程、修改文件、diff、插件和任务状态，不会像命令行那样一开始就有压力。
程序员可以 Desktop + CLI 一起用。Desktop 负责管理任务，CLI 负责在终端里快速调用。IDE 插件适合你正在编辑器里写代码时使用，不用来回切窗口。Cloud 更适合长任务和团队协作。Chrome 插件则是工作自动化方向，后面单独讲。
4.安装方式：先跑起来
4.1 安装 Codex Desktop
如果你是新手，优先安装桌面端。打开官方 Codex 页面，按系统下载 macOS 或 Windows 版本即可。
Codex App 官方文档显示，它支持用 ChatGPT 账号或 API key 登录，并选择本地项目文件夹开始工作。
安装完成后，建议先做三件事：
- 1.登录你的 ChatGPT 账号；
- 2.新建或选择一个项目文件夹；
- 3.在第一个对话里让 Codex 只读项目，不要直接改代码。
不要急着装插件、开自动化、接 MCP。先让它跑一个最小任务玩玩手感。
4.2 安装 Codex CLI
如果你熟悉命令行，可以安装 CLI。官方 Codex CLI 是本地终端里的 coding agent，可以读取、修改和运行你选择目录里的代码。(OpenAI Developers)
常见安装方式：
npm install -g @openai/codex
验证安装：
codex --version
进入项目目录后启动：
codex
也可以直接给任务：
codex "请解释这个项目的目录结构"
CLI 适合开发者。它更快、更直接，但对非技术用户不如 Desktop 友好。
4.3 安装 IDE 插件
如果你日常使用 VS Code可以安装 Codex IDE 插件。
它适合处理编辑器现场的小任务：
解释当前文件、修改选中代码、给组件补测试、根据 diff 写 commit message。
4.4 Chrome 插件先别急着开
Chrome 插件很强，但也更敏感。它的作用是让 Codex 使用你 Chrome 里的登录状态，处理需要登录的网站任务。官方文档明确提到，Codex Chrome extension 适合那些需要 signed-in browser state 的浏览器任务，比如需要读取或操作已登录网站。(OpenAI Developers)
如果你只是刚入门，不建议第一天就开这个。先把本地项目里的读代码、改代码、看 diff 跑顺，再研究网页自动化。
5.第一次使用 Codex：别直接让它做大项目
第一次打开 Codex，最常见的错误是直接说：
“帮我做一个完整系统。”
这类需求太大，边界不清楚，AI 很容易写出一堆看起来热闹但很难维护的东西。
正确流程应该是：先读项目，再解释结构，再做小改动，最后才做功能。
第一步：只读项目
第一次进入项目，先输入：
先不要修改任何代码。
请通读当前项目，并回答：
1. 这个项目是做什么的；
2. 使用了哪些技术栈；
3. 主要目录结构是什么；
4. 启动命令是什么；
5. 测试或类型检查命令是什么；
6. 首页或主入口文件在哪里；
7. 如果我要新增一个页面，应该从哪里开始。
这条指令的重点是“先不要修改任何代码”。你不是让它马上干活，而是先让它建立上下文。很多项目本身没有文档，Codex 可以先帮你补一个“口头项目说明”。
第二步：解释关键模块
比如你想了解选题管理、登录、订单、课程报名这类模块，可以继续问：
请重点解释当前项目里的“内容列表”模块。
请说明：
1. 页面文件在哪里；
2. 数据从哪里来；
3. 组件之间如何传递数据；
4. 有没有状态管理；
5. 如果我要增加筛选功能，大概需要改哪些文件。
仍然不要修改代码。
这一步用来判断 Codex 是否真的看懂了项目。如果它只能泛泛而谈，不适合马上交给它复杂任务。
第三步：做一个极小修改
比如：
请把首页主按钮文案从“开始使用”改成“立即体验”。
要求：
1. 只修改必要文件；
2. 不调整样式；
3. 不改其他文案；
4. 修改后告诉我改了哪个文件。
小任务不是为了省时间，而是为了测试它的执行边界。一个小文案都能精准改，后面才值得让它做功能。
第四步：做一个可验证的小功能
比如给列表页加搜索：
请给当前列表页增加一个搜索框。
要求：
1. 复用现有样式；
2. 不引入新的 UI 库；
3. 支持按关键词过滤列表；
4. 不修改后端接口；
5. 修改后运行类型检查；
6. 最后总结修改了哪些文件，以及如何验证。
这个任务大小比较合适：有上下文、有边界、有验收标准。Codex 最适合从这类任务练起。
第五步：检查 diff
无论 Codex 总结得多好，都不要跳过 diff。你可以让它先自查：
请总结当前 diff：
1. 修改了哪些文件；
2. 每个文件为什么修改；
3. 有没有无关改动；
4. 有没有潜在风险；
5. 是否运行了测试或类型检查。
然后你再自己看一遍 Git diff。如果一个小任务改了几十个文件，要警惕。
6.基础能力：读代码、改代码、修 Bug、写测试
Codex 的基础能力可以归成四类。
别急着学高阶功能，
先把这四件事用顺。
6.1 读代码
读代码是最稳的入门场景。
适合接手旧项目、学习开源项目、理解外包交付项目，
也适合产品经理理解研发实现。
提示词：
请解释这个项目的整体架构。
输出格式：
1. 项目用途；
2. 技术栈；
3. 目录结构；
4. 核心模块；
5. 数据流；
6. 启动方式；
7. 新人上手建议。
不要修改代码。
如果你做内容或培训，可以让它进一步生成“给非程序员看的解释版”：
请把上面的项目结构解释成非程序员也能听懂的版本。
不要出现太多术语，如果必须出现，请顺手解释。
这个用法非常适合做技术课程、工具教程、内部培训材料。
6.2 改代码
改代码时，必须写清楚“哪些不能变”。很多 AI 出问题，
不是因为不会写，而是因为为了完成目标顺手改了不该改的地方。
示例：
请重构当前组件。
目标：
1. 降低组件复杂度；
2. 抽离重复逻辑；
3. 保持现有功能不变；
4. 不修改对外 props；
5. 不改变样式表现。
执行前请先给出计划，等我确认后再修改。
尤其是“保持现有功能不变”“不修改对外 props”这种限制，
要写出来。
AI 不会天然知道你的隐性规则。
6.3 修 Bug
修 Bug 时，不要只贴一句“报错了”。要贴完整报错、操作步骤、期望结果。
提示词：
我遇到了下面这个报错：
[粘贴完整报错]
复现步骤：
1. 打开某个页面；
2. 点击某个按钮；
3. 出现报错。
请按步骤处理：
1. 解释报错含义；
2. 判断最可能的原因；
3. 列出你要检查的文件；
4. 给出修复计划；
5. 等我确认后再修改代码。
如果已经允许它修改，可以加一句：
修复后请运行相关测试或启动命令，确认问题是否解决。
6.4 写测试
写测试很适合交给 Codex。因为测试规则明确，重复性强，也方便验证。
提示词：
请为当前模块补充测试。
要求：
1. 参考项目已有测试风格；
2. 覆盖正常情况、异常情况和边界情况；
3. 不修改业务逻辑；
4. 测试文件命名遵循项目规范；
5. 写完后运行测试并汇报结果。
如果项目没有测试，可以先让它检查：
请先检查当前项目是否已有测试框架和测试示例。
如果有，请说明测试框架、测试命令和推荐写法。
如果没有，请给出最小化测试方案，先不要安装依赖。
7.Prompt 写法：不要聊天，要派任务
Codex 不是普通聊天工具。你要像给同事派任务一样写指令。最实用的结构是四个部分：目标、背景、限制、验收标准。
差的写法：
帮我优化一下页面。
这个指令太空。优化什么？速度、样式、交互、结构还是 SEO？Codex 只能猜。
好的写法：
【目标】
优化当前文章列表页的加载速度。
【背景】
这是一个 Next.js 项目，文章列表页目前首屏加载偏慢。
【限制】
1. 不改变页面视觉效果；
2. 不修改后端接口；
3. 不引入新的状态管理库；
4. 优先检查重复请求和不必要渲染。
【验收标准】
1. 给出性能问题分析；
2. 修改前先列出计划；
3. 修改后运行类型检查；
4. 总结修改文件和验证方式。
写得清楚，不是为了显得专业，而是为了减少返工。
一个简单判断标准：
如果这个需求交给真人同事也听不明白，
那 Codex 大概率也会跑偏。
8.Plan 模式：复杂任务先规划
只要任务会影响多个文件，就应该先规划。尤其是登录、权限、数据库、支付、部署、大规模重构，不要让 Codex 直接动手。
提示词：
请先进入计划模式，不要修改代码。
任务：
给当前项目新增“文章收藏”功能。
请输出：
1. 需要修改哪些文件；
2. 每个文件准备做什么；
3. 是否需要新增依赖；
4. 是否涉及数据结构变化；
5. 可能的风险点；
6. 验证方式。
等我确认后再执行。
这个习惯会让你少踩很多坑。
9.AGENTS.md：给 Codex 的项目说明书
如果你长期在一个项目里使用 Codex，建议在项目根目录放一个 AGENTS.md。它相当于项目说明书，把技术栈、启动命令、代码规范、禁止事项写清楚。
示例：
# AGENTS.md
## 项目简介
这是一个内容选题管理工具，用于记录选题、平台、状态、发布时间和复盘数据。
## 技术栈
- Next.js
- TypeScript
- Tailwind CSS
- shadcn/ui
- SQLite
## 常用命令
- npm run dev：启动开发环境
- npm run build：构建项目
- npm run lint：运行 lint
- npm run test：运行测试
## 代码规范
- 使用函数组件；
- 所有组件使用 TypeScript；
- 样式优先使用 Tailwind；
- 不要引入新的 UI 库；
- 不要修改数据库结构，除非任务明确要求。
## 目录说明
- src/app：页面
- src/components：通用组件
- src/lib：工具函数
- src/db：数据库相关代码
## 注意事项
- 修改超过 3 个文件前，必须先给出计划；
- 涉及数据删除操作时，必须等待人工确认；
- 完成任务后必须总结修改内容。
有了这个文件，你不用每次都从头讲规则。Codex 进入项目后，能更快贴近你的项目习惯。
10.Codex for Chrome：把浏览器里的重复动作交给 AI
Codex for Chrome 是一个很关键的变化。它让 Codex 不只待在代码项目里，而是可以在授权后使用你的 Chrome 登录状态，处理一些网页任务。官方文档对它的描述是：当 Codex 需要读取或操作需要登录状态的网站时，可以使用 Chrome extension。(OpenAI Developers)
这类任务一般有三个特征：路径固定、动作重复、结果可以人工复核。
举个内容团队的例子。每周复盘时，可以利用它复盘数据。这个流程不复杂，但很耗时间。你可以让 Codex 先整理数据：
请打开我已经登录的几个内容平台后台，整理最近 7 天的数据。
需要记录：
1. 内容标题；
2. 发布时间；
3. 阅读量或播放量；
4. 点赞、收藏、评论；
5. 新增粉丝；
6. 表现最好的 3 条内容。
请先整理成表格，不要发送给任何人。完成后等我检查。
这里的重点不是让 Codex 替你判断哪条内容一定能爆，而是让它先完成“打开网页、读取数据、整理表格”这些重复动作。最后哪些数据有效、怎么复盘，仍然由人判断。
同样的逻辑可以放到其他场景：
教培机构整理学员签到和作业提交情况；
招聘团队汇总候选人面试状态；
行政同事检查供应商资料是否缺字段；
活动运营把多个报名页面的数据合成一张表……
11.内置浏览器、Chrome 插件、Computer Use、MCP 有什么区别？
这几个概念很容易混。
内置浏览器更适合开发场景。比如你让 Codex 启动本地项目，在浏览器里打开 localhost:3000，看页面有没有跑起来，再根据截图修改样式。
Chrome 插件适合需要登录状态的网站。比如内容平台后台、内部系统、邮箱、项目管理工具。
Computer Use 更偏桌面操作，比如某些没有 API、没有网页入口的软件。这个能力更强，但也更需要谨慎。
MCP 和插件是更稳定的连接方式。
如果一个工具有 GitHub、Figma、Notion、数据库这类接口，优先用插件或 MCP。能走结构化接口，就不要让 AI 模拟鼠标点击。OpenAI 官方也把 Plugins 作为 Codex 扩展能力的一部分，用来连接外部应用、skills 和 MCP servers。
12.Skills：把你的经验变成 Codex 的工作流
Skills 不是提示词收藏夹。它更像把一套重复流程封装起来，让 Codex 每次按同样标准执行。
OpenAI 官方文档对 Skills 的解释是：skill 会打包说明、资源和可选脚本，让 Codex 更可靠地遵循某个工作流。
如果你经常做 AI 工具教程，可以做一个“工具拆解 Skill”。规则可能是：
当我让你拆解一个 AI 工具时，请按以下结构输出：
1. 这个工具解决什么问题；
2. 适合什么人；
3. 主要功能；
4. 新手怎么上手；
5. 三个真实使用场景；
6. 和同类工具的区别；
7. 适合做成什么内容选题。
如果你做企业 AI 培训，可以做一个“培训课件 Skill”：
当我给你一个 AI 工具主题时，请帮我生成半天培训方案。
输出：
1. 培训对象；
2. 培训目标；
3. 课程模块；
4. 每个模块的讲解重点；
5. 现场练习；
6. 学员作业；
7. 讲师提示。
如果你是开发团队，可以做“代码审查 Skill”：
审查代码时，请优先关注：
1. 是否有明显 Bug；
2. 是否破坏现有 API；
3. 是否存在安全风险；
4. 是否缺少必要测试；
5. 是否有过度设计；
6. 是否有无关文件被修改。
只标出重要问题，不要纠结格式偏好。
Skills 的意义是沉淀自己的工作习惯。
你反复说过十遍的规则，就不应该每次都手动复制。
把它变成 Skill，才是把 Codex 从“聊天工具”变成“个人工作台”的关键。
13.Automations：适合做定时检查，不适合无脑执行
Automations 可以让 Codex 按计划在后台执行 recurring tasks。官方文档也提到，它可以把发现结果放进 inbox，如果没什么可报告，也可以自动归档；同时可以和 Skills 组合使用。
注意，这个功能最适合“检查”和“整理”，不适合一上来就做高风险自动执行。
比如内容团队可以设置一个每周五自动任务：
每周五下午，检查本周内容项目的更新情况。
请整理：
1. 本周新增了哪些选题；
2. 哪些选题已经发布；
3. 哪些选题卡在待修改状态；
4. 哪些内容数据表现最好；
5. 下周建议优先推进的 5 个选题。
输出一份周报草稿，等我确认后再使用。
开发团队可以设置：
每天早上检查当前项目状态。
请整理：
1. 昨天新增的问题；
2. 仍未关闭的高优先级任务；
3. 最近失败的构建或测试；
4. 需要人工 review 的分支；
5. 今天建议优先处理的事项。
只生成报告，不要自动修改代码。
培训团队也可以用：
每周一上午检查课程资料库。
请整理：
1. 本周要交付的培训主题；
2. 哪些课件还没准备；
3. 哪些案例需要更新；
4. 哪些工具最近有重大更新；
5. 建议补充的练习题。
只输出清单，不要修改文件。
Automations 的价值不是“让 AI 替你上班”，而是把每天、每周固定要看的材料提前摆好。它像一个定时醒来的助理，不是一个可以无限放权的员工。
14.MCP 与插件：把 Codex 接进真实工具
当 Codex 只待在本地项目里，它主要是编程助手。
当它接入 GitHub、Figma、Notion、Linear、数据库、Slack 这些工具后，
才开始像一个工作流 Agent。
典型场景有几个。
第一，接 GitHub。你可以让 Codex 总结某个 PR 改了什么、有哪些风险、review 评论怎么处理，也可以让它根据 issue 生成实现计划。
第二，接 Figma。设计稿不是截图，而是结构化节点。通过插件或 MCP，Codex 可以读取设计结构，再生成更接近设计稿的前端组件。也可以直接用codex里自带的图像工具转为前端代码，实现像素级复刻。详细看我上周的文章里面有，往前翻一下🍎🍎🍎
第三，接项目管理工具。比如把待办任务拉出来，按优先级排序，或者把完成情况整理成周报。
第四，接数据库。这个场景要谨慎。更适合查询和分析，不建议让 Codex 直接改生产数据。这个之前也写过，都可以直接搜下关键词supabase🤔😂
一个比较稳的用法是：
请读取项目管理工具里本周标记为“待处理”的任务。
请按以下格式整理：
1. 任务标题；
2. 所属模块；
3. 优先级；
4. 是否阻塞其他任务；
5. 建议处理顺序。
只整理，不修改任务状态。
MCP 和插件的关键不是“接得越多越好”。
根据自己需求安装即可。
15.多 Agent ：不要同时乱跑，要分清任务边界
Codex 支持多线程、多项目、worktree 等能力。OpenAI 官方功能页也提到，Codex App 支持 side-by-side 的项目线程和内置 Git worktree，用来隔离并行代码变更。
直接执行
codex features enable multi_agent
配置文件 ~/.codex/config.toml 里加个并发上限参数，就是最多允许几个的意思。它就会自己spawn_agent。
这很有用，但不能乱用。
正确用法是把任务拆清楚。比如你要做一个内容选题管理工具，可以分成三个线程：
线程 A：实现选题列表和状态筛选。
线程 B：设计数据结构和本地存储。
线程 C：生成 README 和使用说明。
这三个任务之间有边界，不容易互相踩文件。如果你让三个 Agent 同时改同一个核心组件，大概率会冲突。
多 Agent 的建议：
- 1.每个线程只负责一个明确任务；
- 2.尽量避免多个线程同时改同一批文件；
- 3.每个线程完成后先看 diff；
- 4.合并前让 Codex 总结冲突风险；
- 5.重要变更必须人工 review。
多 Agent 并行的价值不是炫技，
而是把可以并行的任务分出去。
你要像分配同事工作一样分配 Codex，
而不是让它们在同一个文件里打架。
16.实战案例：用 Codex 做一个“公众号选题管理工具”
下面给一个完整案例。这个案例适合普通人，也适合程序员练手。目标不是做一个复杂系统，而是做一个自己能用的小工具。
16.1 项目目标
第一步：让 Codex 设计方案
我想做一个本地运行的“内容选题管理工具”。
请先不要写代码，先给我方案。
功能要求：
1. 可以新增选题；
2. 可以编辑选题；
3. 可以按状态筛选；
4. 可以按平台筛选；
5. 可以搜索标题；
6. 可以记录发布时间和复盘备注；
7. 数据先保存在本地，不做登录。
请输出：
1. 推荐技术方案；
2. 页面结构；
3. 数据结构；
4. 需要创建哪些文件；
5. 第一个最小可用版本怎么做。
这一步只要方案，不要代码。先看它怎么拆。
第二步：让它做最小版本
请实现第一个最小可用版本。
要求：
1. 使用当前项目已有技术栈；
2. 页面包含选题列表、搜索框、状态筛选、新增选题按钮；
3. 数据可以先写死在前端数组里；
4. 不接数据库；
5. 不引入新的 UI 库；
6. 完成后运行类型检查；
7. 最后告诉我如何打开页面。
这里故意先不用数据库。先让页面跑起来。
第三步：增加本地保存
请把选题数据改成本地保存。
要求：
1. 使用 localStorage；
2. 支持新增、编辑、删除；
3. 刷新页面后数据仍然存在；
4. 不接后端；
5. 不改变现有页面布局；
6. 修改前先说明会改哪些文件。
这个功能仍然可控，适合练 Codex。
第四步：增加复盘字段
请给每条选题增加“数据复盘”字段。
字段包括：
1. 阅读量或播放量；
2. 点赞数；
3. 收藏数；
4. 评论数；
5. 复盘备注。
要求：
1. 列表页显示核心数据；
2. 编辑弹窗里可以修改；
3. 不影响已有数据；
4. 如果老数据没有这些字段，请做兼容处理。
这里开始接近真实使用。你会看到 Codex 是否能处理旧数据兼容。
第五步：生成使用说明
请根据当前项目，生成一份 README。
要求：
1. 说明这个工具是做什么的；
2. 说明如何安装依赖；
3. 说明如何启动；
4. 说明主要功能；
5. 说明数据保存在什么地方；
6. 说明后续可以扩展哪些功能。
这就是一个完整的小项目流程：
先方案，后最小版本，
再迭代，再写文档。
普通人也能照着走。
17.真正要学的不是 Codex，而是怎么派活
Codex 当然是一个工具，但只把它当工具看，会低估这件事。
它真正带来的变化，是人和软件生产之间的分工变了。这里的关键不是“AI 有多聪明”，而是你会不会派活。
任务说不清楚，Codex 就会乱猜。边界不给，它就可能多改。验收标准没有，它就不知道做到什么程度算结束。你把它当聊天对象，它就给你聊天式回答；你把它当执行者，就要给目标、背景、限制和验收标准。
对新手来说，先记住一条就够了：不要让 Codex 猜你的需求。
这也是我为什么把这篇叫《阿星Codex 编程白皮书》，而不是简单叫“Codex 教程”。
教程解决的是怎么点按钮。白皮书解决的是怎么建立一套方法。
Codex 只是开始。真正重要的是，我们要学会和 Agent 一起工作。
ok，我是阿星，更多AI应用，我们下期再见！
