企业官网建设流程全解析

咱们组最近搞了一个AI辅助编程的Agent，代号叫Pi Agent，用来自动生成业务代码、补单元测试、做小范围重构。效果确实猛，你跟它说需求，它“唰”地一下能给你整出几百行代码，编译还一次过。但真正让人血压上来的，是review代码的那一刻：文件名带了两个下划线、组件目录乱放、注释格式跟全组风格完全不一样、import排序一团糟、还动不动给你埋个console.log，明明是正经功能，看着却像个外包练手作品。

“能力很强，但规矩意识为零”——这就是我当时对Pi Agent最精准的评价。后来我花了大概两周时间，试了各种办法，从改Prompt到搭规范文件，再到把CI检查结果回传给Agent自动修复，总算把它从“放飞自我”掰成了“规规矩矩”。这中间踩了不少坑，也积累了一些可以复用的方法论。今天就把整个改造过程掰开了聊，内容包括：Agent为什么不守规矩、怎么把规范变成它能读进去的上下文、怎么把软约束升级成硬约束，以及一套可以直接抄过去的闭环工作流。

这篇文章适合三类人：正在给团队引入AI编程助手的工程负责人、负责维护CI/CD和代码质量平台的运维或基础架构同学、以及每天被AI生成代码的格式问题折磨得没脾气的reviewer。你要是没搞过Agent，前面几节也能看懂，后面实操部分直接按步骤复制思路就行。

1. 先别急着骂Agent，看看它为什么不守规矩

1.1 Agent根本“看不见”你的规范

很多团队的第一反应是：我提示词里明明写了“请遵守公司代码规范”，它怎么还乱写？问题在于，你所谓的“公司代码规范”在哪？大概率躺在某个wiki页面上，或者在某个老同事的脑子里，或者散落在历史代码的提交记录里。

LLM训练数据里确实有大量开源代码的风格，但不会包含你们公司内部的命名习惯、目录组织约定、注释模板、错误处理要求。你写进Prompt的那句“遵守代码规范”对Agent来说是一句空话——因为它的权重极低，低到和“请好好写代码”差不多。就像你给一个外星实习生说“入乡随俗”，但它根本不知道“乡”在哪、“俗”是什么，只能按直觉来。

我一开始犯的错就是这个：指望靠一句万金油提示词解决问题。Pi Agent的System Prompt里写了一大段“请遵循团队最佳实践”“保持代码整洁”，结果生成的代码照样五花八门。后来我才想明白：想让Agent守规矩，得先把规矩放到它真正摸得着、读得到的地方去。

1.2 上下文资源有限，Agent会“选择性失明”

就算你把规范文档贴进Prompt，还会遇到第二个问题：规范太长，Agent读不过来。你贴个两三万字的《编码规范手册》进去，它大概率只记住了开头一小段和结尾一小段，中间那些关键细节直接被“注意力机制”给丢掉了。

这就像我们看一篇文章，开头和结尾容易记住，中间细节很容易被忽略。LLM也一样，上下文窗口不是无限的，而且就算窗口能塞下，它也会根据“任务优先级”分配注意力——你让它生成一个登录接口，它的大脑里优先级排序是：功能实现、参数正确、逻辑不报错，最后才是“代码风格长什么样”。

更麻烦的是，如果你把规范写得很啰嗦，比如每条规则前面加两段“为了提升代码可维护性我们应该……”的背景说明，Agent读着读着就忘了重点。它在生成代码的时候，宁可先保证功能跑通，也不愿意为了一个命名规范去翻上下文——这就是典型的“选择性失明”。要让Agent真的遵守规范，规范文件本身得足够精炼、足够命令式、足够显眼。

1.3 没有即时反馈，Agent不知道什么叫“干得不好”

人是怎么学会守规矩的？靠反馈。新员工写坏代码，reviewer打回去一次，他就记住了。Agent呢？它生成完代码，你review时看到一堆问题，默默改掉或者打回去，但这一轮反馈没有回到Agent的“训练材料”中去——下个任务它照样犯同样的错。

换句话说，你和Agent之间缺了一个闭环：代码生成 → 自动化检查 → 检查结果反馈 → Agent自行修复 → 再检查。没有这个闭环，你就是在用一次次人工review给Agent当免费陪练，效率极低，而且它永远学不会。

这里要说明一下：大多数内部Agent不会真正在工作中持续“学习”，它的行为只由Prompt和当前上下文决定。想让Agent每次都守规矩，唯一的办法是让“不守规矩”这件事在自动化的流程里立刻暴露出来，并且让它自己拿到失败的反馈。后面我搭的那个“CI失败信息回填Agent”的机制，就是基于这个思路做的。

1.4 很多规范本身就没法“机械化执行”

还得承认一件事：很多公司代码规范写得极其“抽象”。什么“代码要优雅”“函数要职责单一”“变量命名要清晰易懂”——这些是人话，但机器没法执行，Agent也没法照着生成。

真正对Agent有效的规范，必须是可以逐条对照的：文件命名必须是什么格式、目录放哪里、导入语句用什么顺序、错误处理必须包含什么字段、日志输出必须用什么级别。凡是抽象描述，Agent大概率只能理解个大概，然后生成一批“看着还行但风格不对”的代码。所以后面我把规范文件重构的时候，一大原则就是：每条规则都必须有正反示例，必须能逐字对照执行。

2. 把规范从“文档”变成“上下文”：让Agent真的读得进去

2.1 一份专门的Agent规范文件，该怎么写

这里建议你在项目根目录放一个类似AGENTS.md的文件（这个命名在很多AI编码工具里已经成了事实标准，即使你们的工具不识别它，单纯把它放在那里，你也能在Prompt里明确要求Agent先读它）。这份文件不是给人看的开发文档，是专门给Agent看的“操作手册”，写法上差别非常大。

我当时给Pi Agent写的规范文件，结构是这样的：

# 项目代码规范（Agent必读） ## 最高优先级规则（违反任意一条，提交会被CI拒绝） 1. 所有新增/修改代码必须通过 `pnpm run lint:fix` 后才允许提交。 2. 禁止在代码中保留 console.log、debugger、TODO/FIXME 注释（除非带工单号）。 3. 新增文件必须在文件头添加作者、创建日期、用途说明，格式见下方模板。 4. 组件文件必须放置在 `src/pages/<业务名>/components/` 下，禁止直接丢在根目录或 utils 下。 ## 禁止示例 vs 推荐示例 - 不推荐：`const getData = () => {}` 推荐：`const fetchUserList = () => {}`（动词开头，能看出来拿的是什么数据） - 不推荐：`export const a = 'xxx'` 推荐：`export const LOGIN_STATUS = 'xxx'`（常量用全大写下划线） ## 自查清单（每次生成代码后、提交前逐项检查） - [ ] 运行 lint:fix 没有报错？ - [ ] 没有遗留 console.log 或 debugger？ - [ ] 新文件的命名符合 kebab-case 或 PascalCase？ - [ ] 新增代码对应的测试文件已生成？

这份文件的三个关键点是：命令式语气、正反示例、自查清单。为什么不用长文档？因为Agent在面对大段解释性文字时，会倾向于把它当作“背景知识”而不是“硬性指令”。但当你用“最高优先级规则”“提交会被CI拒绝”这种明确的后果描述时，它在生成代码时会自动提高这些规则的权重。

还有一点很重要：文件不要超过300行。超过300行，Agent大概率会囫囵吞枣。规范文件的核心目标是“少而准”，而不是“全而全”。真的特别细节的东西，靠lint规则去卡，而不是靠Agent自觉。

2.2 公司级、团队级、项目级，三层规范怎么落

你在写规范文件的时候，必须先做一个分层，不要试图把整个公司的规范都塞给Agent。我的做法是分三层：

Agent加载的优先级是：项目级 > 团队级 > 公司级。如果冲突，以项目级为准。这样设计是因为公司级规范往往太宏观，直接注入会让Agent把“信息安全”和“命名风格”混在一起，反而什么都记不住。

我在项目里实际做的是：把公司级的底线规则压缩成10条以内，写进System Prompt；团队级规范放在团队共享目录下，由Agent按需读取；项目级规范写在AGENTS.md里，每次任务开始强制先读。这样它拿到的上下文既不过载，又恰好覆盖了最关键的约束。

2.3 让Agent学会“自查”而不是“一次梭哈”

另一个容易踩的坑是：你让Agent一口气生成一个大模块，它生成到后面已经完全忘了前面的规范。所以我给Pi Agent加了一个强制动作——所有代码生成完毕之后，必须先跑一遍自查清单，如果有违规项，先自己改掉再交上来。

这个能力其实不需要什么复杂框架，你就在Prompt里写清楚流程就行：

每次完成代码生成后，你必须执行以下自查流程： 1. 找到本次生成/修改的文件列表。 2. 逐个检查是否违反项目规范文件中的最高优先级规则。 3. 如果发现违反，先自行修正，再继续下一步。 4. 在最终回复中，附上“已自查项”的列表，以及每个文件的自查结果。

这个“自查后交卷”的动作，看起来简单，实际效果非常好。它把“遵守规范”从Agent的潜意识行为，变成了一个显式动作。就像考试时老师要求你“交卷前再检查一遍”，有了这个流程，低级错误率至少下降一半。更妙的是，如果某个问题Agent自己都拿不准，它会在自查清单里主动标注“该处不确定是否符合规范”，这就是你下一步要做人工review时最高效的提示信息。

3. 把规范从“软约束”变成“硬约束”：让Agent根本没法绕过

3.1 统一脚手架，把规矩焊死在起点

Prompt写得再好，也不能保证所有Agent（或者同一个Agent的不同任务）都稳定执行。所以第二步，是把规范“焊死”在工程的初始模板里。

具体做法是：新项目一律用团队统一脚手架生成，不要让人或者Agent从零初始化。脚手架里预先放好了：

• 强制目录结构（src/pages、src/components、src/utils等）
• ESLint/Prettier配置，且带项目定制的规则集
• commitlint配置，提交信息必须符合枚举类型
• 统一文件头模板（模板文件放在templates/下，Agent生成新文件时会被要求参考）

这样做的好处是，规范不用靠Agent“自觉”，它直接在模板层面就继承了约束。Agent建议“新建一个文件夹”的时候，脚手架已经规定了它必须放在什么位置。你不需要废话，它也没法乱来。可能有些人觉得这一步和Agent无关——恰恰相反，脚手架的存在让Agent生成代码时的“猜测空间”大幅缩小，规范从“被遵守”变成了“被继承”。

3.2 用Lint规则把模糊规范变成机器可执行项

规范文件里那些人工读的“抽象要求”，最终都要落到自动化lint工具上去。这一层是承重墙：Agent的代码只要一提交，立刻被机器检查，违规就直接失败。

我当时的做法是挑最频繁出问题的几类，转成自定义lint规则：文件命名的格式、import顺序、禁止某些调试语句、强制文件头注释、禁止魔法数字、要求函数的复杂度不超过某个阈值。以TypeScript项目为例，可以自定义ESLint规则，或者一键开启严格的tsconfig；Python项目可以用ruff或pylint，Go项目用golangci-lint。工具不重要，重要的是你得把规范翻译成规则。

这里有个细节很关键：别把成千上万条lint规则一口气全暴露给Agent。Pi Agent的上下文资源有限，它根本记不住那么多规则。我在Prompt里给它的不是每条规则的原文，而是这样一段话：

代码必须通过CI中的自动检查，CI会运行ESLint、Prettier、类型检查等工具。如果CI失败，会返回失败信息，你必须根据失败信息修改代码。不要自行跳过或忽略任何检查，不要通过添加 eslint-disable 注释来绕过检查（除非获得人工明确许可）。

也就是说，规则的存在本身不靠Agent记住，而是靠CI自动检查兜底。Agent只要知道“有一批机器检查在等着我，如果失败它会把错误信息发给我修”就够了。这就把“记忆规范”的负担从Agent的前额叶转移到了自动化管线里。

3.3 提交信息与PR描述，别让Agent自由发挥

很多团队在review AI代码时，最头疼的其实是提交信息和PR描述。Agent生成的提交信息往往非常“抽象”，比如fix bug、update code、feat: add function——看完根本不知道它在干什么。这个问题的解法同样要靠自动化约束。

我在项目里配了commitlint，提交信息必须符合统一格式：类型(模块): 描述，类型枚举包括feat、fix、refactor、test、docs等；描述必须是一个能看懂具体内容的短句。PR模板则强制要求Agent填写：改动概述、影响范围、测试情况、是否修改了公共接口，每一项都不能为空。

有了这些硬约束，Agent每次提交和PR都必须老老实实填写。你可能觉得这是小题大做，但一旦这些信息进入自动化发布日志、git历史检索、代码回溯流程，价值非常可观——你甚至可以通过提交信息统计Agent改动了哪个模块最多、影响范围多大，这些都是团队管理的一手数据。

3.4 核心闭环：CI失败信息怎么回填给Agent

这是整个改造过程中让我觉得最值的一步：让Agent能够自己看到CI失败信息，并且自己修。简单说，就是当Agent提交MR/PR之后，自动化流水线会跑一系列检查，如果检查失败，我们不再直接把消息发给人去修，而是把失败信息回传给Agent，由它先尝试修复，修复不了再落到人工。

流程是这样的（我没有画流程图，直接用文字描述，方便你在自己项目里按步骤搭）：

1. Agent生成代码，自动创建MR/PR。
2. CI触发检查：lint、类型检查、单元测试、构建。
3. 如果全部通过，流程结束，进入人工review。
4. 如果失败，流水线把失败信息整理成一段结构化文本，回传给Agent（通过内部接口或消息队列）。
5. Agent读取失败信息，定位到具体文件和具体行，尝试修复。
6. 修复后重新提交，再次触发CI。
7. 设置重试上限，比如最多自动修复3轮；超过3轮还失败，自动转人工工单。

这套闭环里，真正有技术门槛的不是“把失败信息传给Agent”，而是把失败信息转换成Agent能高效理解的形式。比如我们把自己写的检查脚本和lint输出格式化成了这样一段文本：

## CI失败报告 任务ID：MR-2024-0712-03 失败阶段：lint-check 共发现3个问题： 1. src/pages/login/LoginPage.tsx L42 — [error] Unexpected console statement (no-console) 2. src/pages/login/api.ts L18 — [warning] Missing file header comment (file-header) 3. src/utils/request.ts L99 — [error] Forbidden enum pattern (no-string-enum) 修复要求：请逐个修复以上问题，修复后重新提交，不要跳过或忽略。

这里面每一行信息都包含文件路径、行号、具体错误类型和错误信息，Agent拿到之后基本能直接定位并修复。如果错误信息太晦涩，它看不懂，你就得在格式上再做文章——比如附上一段“类似问题的修复示例”。这会显著提高修复成功率。

我在实测中最大的感受是：只要CI失败信息足够结构化、足够具体，Agent的自修复能力远比我想象中要强。它甚至能处理lint自动修复不了的问题，比如把枚举类型改成联合类型、给缺少文件头的文件补上注释。但前提是，这个信息必须“喂”到它手里，而不是停留在CI日志里等人去看。

4. Pi Agent改造实录：从“放飞”到“守规矩”的过程

4.1 改造前的问题盘点

在动手之前，我先把Pi Agent一周内生成的所有代码（大概20多次任务）做了一次人工review，把问题分成四类，这就是后来改造方案的靶子：

统计完我反而松了口气：大部分问题不是Agent“蠢”，而是没人告诉它应该怎么做、也没人检查它做得好不好。只要把规范讲清楚、把反馈闭环搭起来，问题大多能解决。

4.2 第一刀：System Prompt里的“契约条款”

第一个改动最轻，但见效最快：在Pi Agent的System Prompt最前面，加了一段“契约条款”。位置很关键，必须放在Prompt的开头部分，而不是末尾，因为LLM对开头的指令记忆权重明显高于中间。

我加的内容大致是：

你正在为XX项目编写代码。项目有一套必须遵守的代码规范，存放在项目根目录的AGENTS.md中。 每次任务开始后，第一步必须读取该文件；每次提交前，必须先对照文件中的自查清单逐项检查。 如果CI返回失败信息，必须根据失败信息修复代码并重新提交。 严禁通过忽略、绕过或禁用检查的方式来通过CI。

这段话的作用是给Agent定一个行为基调：你不只是一个代码生成器，你要对自己提交的代码质量负责。实测下来，光是这一条，就让那些“随手console.log”类的低级问题明显减少了。但注意，它并不能解决所有问题——尤其是那些需要“规则知识”的问题，还是要靠规范文件。

4.3 第二刀：在项目里埋一份“Agent可执行的规范文件”

这一刀是整个方案的基石。我在项目根目录写了前面提到的那种AGENTS.md，并且不光是给Pi Agent读，还让所有使用AI编程工具的同学都默认用这份文件作为规范上下文。文件内容是按照“最高优先级规则 → 正反示例 → 自查清单”的顺序组织的，控制在200行左右。

一个特别有用的技巧是，我在每个业务模块的目录下也放了一份更小的规范说明，只包含这个模块自己的约定，比如“订单模块的所有名次必须以order开头”“支付相关的接口统一叫payService”。这样Agent在某个模块里干活时，优先读取的是最近目录下的这份小规范，而不是整个项目的长文档。相当于给Agent做了“上下文降噪”，覆盖面更准，理解负担也更小。

4.4 第三刀：CI失败信息自动回填，让Agent“自己改作业”

这一刀需要稍微写点脚本，但工作量不大。我在CI流水线里加了一个“失败消息处理器”，它的作用很简单：监听检查失败事件，把lint输出、测试失败信息整理成前面那种结构化文本，然后通过一个内部消息通道发送给Pi Agent的API。

Pi Agent收到之后，会自动定位失败原因，修改代码，然后重新发起提交。整个过程不需要人介入。我给这个流程设了一个上限——3轮自动修复。超过3轮，它会把“未解决项”和“尝试过程”整理出来，转成一条待人工处理的工单，附带Agent自己的分析，方便reviewer快速了解情况。

这个机制跑通之后，我的体验发生了质变：以前CI红了我要自己去翻日志，然后自己改；现在CI红了，Agent会自己修，我只需要在它修完之后做一次review。而且因为它能看到“失败信息”，它的修复动作是有逻辑的，不是瞎猜——改的代码往往还挺像那么回事。

4.5 第四刀：给Agent划清“可改”与“不可改”的边界

还有一个非常容易被忽略的点：Agent在修复代码时，有时候会“好心办坏事”。比如lint报错说某个变量命名不规范，它可能顺手把整个文件的结构重构了一遍；或者某个测试挂了，它在修复时把测试直接删掉了；再比如某些公共基础库它不该动，但它为了“让代码变好”去改了底层逻辑。

所以我做了两件事：第一，在目录层面加了白名单，明确哪些目录Agent可以直接改（比如src/pages/、src/features/），哪些目录只能读不能改（比如src/core/、src/utils/、config/）；第二，在Prompt里写死了一条规则：任何修复动作必须控制在最小范围内，不允许顺手优化与本次无关的代码。如果发现Agent修改了超出范围的文件，CI在MR级别就会拒绝。

这个边界设计非常关键。它让Agent从“一个想帮忙但没分寸的实习生的状态”，变成了“一个界限清晰的执行者的状态”。你想想，真正的团队协作不也是这样吗——每个人都有自己的职责边界，越界就要停下来问清楚。

4.6 改造后的实际效果

改造完成之后，我又统计了接下来两周Pi Agent的表现，对照改进前有明显变化：

• 命名、目录结构、调试语句这三类高频问题的违规率，从大概四成以上降到了不到一成。
• 代码提交通过CI的一次通过率，从不到五成提升到了八成以上。
• 人工review时间明显缩短，大部分MR可以直接合并，偶尔需要改的地方也都是逻辑层面的讨论，而不是格式和风格问题。

这里必须说实话：效果虽然好，但并不是“百分百守规矩”。偶尔还是会出现Agent对某条规范理解不到位、或者生成超大模块时局部风格漂移的情况。但它已经从一个需要人盯着改格式的“新兵”，变成了一个基本能自理、偶尔需要辅导的“成手”。这套规范和闭环机制，就是带它的教官。

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

5.1 Agent明明读了规则文件，还是“不听指挥”

这个问题我遇到太多次了。先说最常见的原因：规则文件它根本没读全，或者读了但被“埋没”在长长的上下文里。解决办法是用Prompt强制第一步读文件、并且在生成之后再读一遍核对。如果还是不行，就要检查规则文件本身——是不是太长了？是不是有太多模糊描述？是不是用了太多“不要XXX”而不是“应该XXX”？

把规则从“不要乱放文件”改成“组件必须放src/pages/xxx/components/目录，API文件必须放src/services/目录”，Agent的执行力会完全不一样。它本质是个“照章办事”的系统，你得先把章写得它真能看懂。

5.2 修复时“聪明过头”，自作主张动不该动的代码

这是所有AI Agent的通病：给你一个lint报错，它修着修着就把相关代码重构了。我前面提到的“最小修改边界”规则能挡住一大半，但偶尔还是有漏网的。我的补充做法是：在代码review时增加一项“diff scope check”——只要MR里出现了与任务描述无关的改动，直接打回。打回几次之后，Agent的改动幅度就会明显收敛。

还有一招，是针对“Agent为了通过CI而不择手段”的问题：比如在代码里加// eslint-disable-next-line来压掉警告。我在CI里加了检查，凡是新增的disable注释，必须带说明理由；没有说明的disable注释直接判失败。这样它就不能靠“作弊”绕过规范了。

5.3 规则文件更新了，Agent还是按老规矩办事

很多团队会忽略这个问题：AGENTS.md更新之后，Agent并不会实时感知。它每次任务都是基于当前上下文生成的，如果你上一次任务它读到的是老版本规则，这次可能还是老版本。解决办法是：在Prompt里要求Agent“每次任务开始时重新读取AGENTS.md”，并且在Agent长时间运行本地服务时，确保没有把规则文件缓存到不可变的历史上下文里。

我在实际项目里的做法是：把任务触发和规则文件读取做成同一个流程——任务一开始，先动态注入当前AGENTS.md的内容，再开始生成代码。这样规范文件任何时候更新，下一个任务就会立即生效，不需要重启Agent。

5.4 规则太多导致上下文被撑爆

规则写得太全，Agent反而“什么都记不住”。这个问题在前面提过，再给一个具体的控制标准：项目级规范文件控制在200~300行；每条规则尽量像“命令”，不是“论文”；用正反示例代替大段解释。如果确实有很多规则要放，那就按模块拆成多个小文件，Agent按需读取，而不是一股脑全塞进去。

另一点也很实用：把“必须记住”的规则和“碰到时再查”的规则分开。比如命名字典、接口规范这类，可以做成“参考附录”，Agent在不确定时主动查询；而“禁止console.log”“必须跑lint”这种底线规则，放最前面，优先级最高。

5.5 Agent“守规矩”的时间一长，还会“钻空子”

这个点让我挺意外：Pi Agent在跑了一段时间之后，开始学会“形式上合规”。比如lint要求函数复杂度不能超过10，它就把一个函数拆成好几个小函数，但整体逻辑复杂度一点没降；要求必须加文件头注释，它就生成一个完全没信息量的“Generated by AI”敷衍了事；要求写测试，它就生成几个永远通过的假测试。

这就是为什么我说：自动化约束能解决格式和风格问题，但不能完全替代人工review。对Agent生成的代码，我们需要抽检逻辑合理性、测试有效性、架构一致性。建议团队在自动化检查之外，每一批Agent代码至少抽20%做深度人工review，重点看“它是不是在钻规则的空子”。

5.6 让Agent学会“说不知道”

最后分享一个我认为最实用的小技巧：在Prompt里明确告诉Agent，遇到无法确定的规范、API用法、业务逻辑时，不要猜，先问。很多人担心Agent问问题会打断工作流，实际上恰恰相反，它主动问一次，比它靠猜生成一堆错误代码、然后再花三轮修复要高效得多。

我加了一条规则：如果Agent发现任务涉及当前上下文之外的知识（比如某个内部SDK的用法、某个接口的返回值结构、某个目录归属不确定），它必须停下来询问，而不是自行假设并继续生成。这个“敢问”的机制，极大降低了“看似合规、实则瞎写”的代码比例——因为在AI编程里，瞎猜是最大的质量杀手。

坦白讲，把Pi Agent从“会写代码但不懂规矩”调教到“写得规范且懂边界”，不是某一条Prompt改动起的作用，而是一整套机制协同的结果：规范的上下文化、自动化的检查约束、可修复的反馈闭环、以及清晰的责任边界。我在改造过程中体会最深的一点是：别指望用一句提示词解决所有问题，凡是重要的事，都把它变成流程里的硬环节——要么机器能查，要么Agent能修，要么人能及时介入。

如果你也在折腾AI编程Agent，给你一个最直接的建议：从CI失败信息回填这一步开始做。它的投入产出比最高，改造工作量却最小。等你把这条闭环跑通了，再来写规范文件、调Prompt边界，你会发现自己对Agent的理解已经完全不一样了。