编程代理架构拆解：从AI补全到Agentic Coding的三大典型设计

最近这段时间，我几乎没有再打开过"自动补全"档位的 AI 编程工具。不是补全不好用，而是真正意义上的编程代理（Agentic Coding）已经完全是另一个物种了：它不再等你打完半行代码再猜下一段，而是会自己去翻仓库、改文件、跑测试、看报错，再决定下一步怎么动手。这种从"补全"到"代理"的转变，不是把模型换大一号就能实现的，背后是一整套架构设计的变化。

这篇文章我不想空谈概念，而是选了三个在开源社区里讨论度最高、也最有代表性的编程代理项目来拆。三个项目我都实际部署跑过，也读过它们的源码和设计文档。它们恰好代表了编程代理架构的三个典型方向：一个把"简洁即可靠"做到极致，一个按"完整软件工程师"来设计，还有一个在 IDE 生态里找到了平衡。把这三个拆完之后，你会发现所谓 Agentic Coding 的架构本质，其实就是几个核心问题：谁在控制循环、模型怎么"看见"代码仓库、动作怎么执行落地、以及执行之后如何反馈。把这些搞明白，编程代理在你眼里就不再是黑盒了。

1. Agentic Coding 不是"更强的补全"：先从能力边界说起

1.1 从补全到代理：发生了什么质变

传统的 Copilot 式工具，本质上是一个"条件概率生成器"：给定左侧的上下文，预测右边的 token。它没有目标，没有多步推理，也不具备"调用工具"的能力。而 Agentic Coding 的核心是让模型进入一个感知-推理-行动-观察的循环：模型每走一步，都可以选择调用某个工具（读文件、写文件、执行命令），工具执行完把结果返回给模型，模型根据新的观察继续推理，直到任务收敛。

这个循环听起来简单，但它带来了三个连锁变化。

第一，错误容忍度大幅提升。补全工具写错一行代码，错误就留在了文件里，因为没有人去验证。代理则可以在写完代码后主动运行测试、编译或者 lint，把报错作为下一个观察喂给自己。也就是说，代理具备"试错-修正"的能力，哪怕第一次改错了，它也能从反馈里爬起来。

第二，任务边界从"一个函数"扩大到"整个仓库"。补全是局部的，代理可以先用搜索工具找到相关文件，再读取文件内容，再跨文件修改。它不受"你当前打开的文件"限制，这是完全不同的工作模式。

第三，交互方式从"人按一次 Tab"变成"人发一个目标"。你需要说"把这个项目的登录接口改成 JWT 认证，并更新所有调用方"，剩下的搜索、修改、验证，代理逐步自己完成。这也是为什么很多人把 Agentic Coding 称为"给大模型装上了手和脚"。

1.2 编程代理的三大能力支柱：规划、工具、反馈

拆了多个项目之后，我发现所有编程代理的架构差异，最终都落在这三根支柱上。

• 规划能力：模型怎么把一个高层目标拆成可执行的步骤。有的项目完全靠模型自由发挥，有的项目则引入显式的 Plan 阶段，先输出方案再动手。规划越强，代理在多步任务中的稳定性越好；规划越弱，代理容易陷入"改一个地方坏两个地方"的循环。
• 工具能力：代理能碰哪些东西。文件读写、目录搜索、终端执行、浏览器操作、Git 操作，每一种工具都对应一个接口。工具表面上是"能力范围"，本质上是代理的行动边界——它能干什么，不能干什么，全由工具集决定。
• 反馈能力：行动之后，环境如何把结果回传给模型。测试通过与否、编译报错、lint 警告、文件内容变化，这些反馈的质量和速度，直接决定了代理收敛的效率。

我见过不少团队自己用大模型 API 拼接"读文件+写文件"就号称做了编程代理，结果跑两步就失控。原因不是模型太弱，而是这三根支柱之间缺少衔接：没有规划约束、工具接口不统一、反馈路径断裂。所以拆开源项目时，我最关注的就是这三件事分别是怎么实现的。

1.3 为什么拿开源项目来拆

市面上的编程代理宣传铺天盖地，但真正能让你看清架构的，还是开源代码。闭源产品你只能看到"效果"，开源项目你能看到"设计决策"：为什么这个项目选择用 diff 格式编辑而不是整文件重写？为什么那个项目把事件全部序列化存储？这些决策背后都是作者踩过坑之后的取舍。

我选的三个项目，分别代表了三种设计取向。第一个是把轻量做到极致的命令行结对编程代理：它证明了一个人+一个终端+一个模型，也能形成高效的 Agentic Coding 闭环。第二个是试图构建"全自动软件工程师"的大型框架：事件流架构、沙箱运行、浏览器与终端的全工具覆盖，是学院派和工程派结合的产物。第三个是深度集成在 IDE 里的自主代理：它解决的是"如何在现有开发环境里自然落地"的问题，Plan/Act 双模式的设计非常值得借鉴。

2. 精简到极致的 CLI 结对编程代理：项目 A

2.1 核心循环：编辑请求、应用 diff、提交验证

项目 A 是目前开源社区里使用门槛最低的编程代理之一。装好后，你在仓库目录下启动它，然后直接说"把main.py里那个find_user函数的空指针问题修掉"，它就进入工作循环：读取相关文件 → 生成编辑 → 以 diff 形式返回 → 程序应用修改 → 自动创建一条 git commit。整个过程你可以随时介入，改得不对就说"回退重来"，改得满意就继续下一步。

它的核心循环简单到可以用一张图说清：用户消息进入对话 → 模型生成结构化编辑 → 程序把编辑应用到工作区 → git 提交 → 结果返回模型 → 进入下一轮。这里有个被很多人忽略的细节：它把每一次修改都交给 git 管理，所以代理的每一次改动都是可回退的。这意味着即使模型生成了完全错误的修改，你也可以无损撤销。在很多大型代理项目里，回退能力甚至需要单独设计，而项目 A 用最朴素的 git 就解决了。

为什么这个设计有效？因为 git commit 不仅是版本管理，还充当了**"行动记录"**：模型后续的推理可以从 commit message 里看到自己刚才做了什么改动，用户也可以在对话里看到每次提交的 diff。这个"自带审计日志"的特性，让项目 A 在几乎零附加架构的情况下，实现了可追溯性。

2.2 代码库地图：让代理用最短 Token 看见项目全貌

但项目 A 最让我服气的不是 git 集成，而是它的代码库地图（repo map）机制。编程代理绕不开一个问题：大模型的上下文窗口有限，不可能把整个项目所有文件都塞进去。那代理怎么知道要改哪个文件？怎么知道相关函数在哪里？

项目 A 的答案是：在每次请求时，它用语法解析器扫描整个仓库，生成一棵符号级别的仓库地图，里面记录着每个文件有哪些类、哪些函数、函数之间的调用关系。然后它根据当前任务涉及的文件和符号，只把最相关的那部分 API 签名和高频使用片段拼进上下文。整个地图可能只需要几千个 token，却能覆盖一个中型仓库的骨架。

我把这个机制理解成一张城市交通图：你不需要记住每一栋楼里所有房间的布局，你只需要知道主干道在哪、某个小区大概在什么位置。代理真正需要看到详细文件时，再通过"读取文件"工具去拿具体内容。这种**"先给骨架，再按需取肉"**的策略，是解决上下文窗口限制最优雅的实践之一，后来不少 IDE 插件里的语义索引都借鉴了类似思路。

2.3 为什么"省"反而可靠：少即是多的架构哲学

项目 A 还有一个反直觉的设计选择：它默认采用 diff 格式来做文件修改，而不是让模型输出整个文件然后覆盖。通俗地说，它要求模型只输出"删除哪几行、新增哪几行"，由程序合成最终文件。这样有几个具体好处：上下文里不需要重复粘贴整个文件，模型只需要聚焦变更部分；改动范围小，引入无关错误的风险低；而且代码审查时，一眼就能看到模型到底动了什么。

当然，这个设计也有代价。diff 格式对模型的要求更高，部分模型用它反而表现不稳定。所以项目 A 做了一件聪明的事：根据你所用的模型能力，自动选择 diff 编辑还是整文件重写模式。它把这个决定从用户手里接了过去，变成了一个模型级别的自动配置。

拆完项目 A，我的感受是：编程代理不一定非要复杂才能有用。把循环做短、把反馈做密、把上下文做省，一个几十人维护的开源项目也能支撑起完整的 Agentic Coding 体验。它适合的恰恰是大多数日常开发场景：不是让你把整个项目丢给 AI 全自动做完，而是让 AI 在每一步都和你确认、反馈、迭代。

3. 以"AI 软件工程师"为目标的完整代理系统：项目 B

3.1 事件流架构：把智能体动作变成可回放的事件总线

如果说项目 A 是精巧的瑞士军刀，那项目 B 就是一艘全尺寸航母。它给自己的定位不是"帮你改代码的助手"，而是"自主完成软件工程任务的智能体"。它的核心架构创新，是引入了事件流（Event Stream）。

项目 B 里，所有事情都变成事件：模型产生一个意图，就是一个 Agent Action 事件；执行完动作，环境返回结果，就是一个 Observation 事件；用户发来一条消息，是一个 Message 事件；状态切换，也有对应的状态事件。这些事件全部追加写入同一个事件流中，带有顺序和时间戳。UI 只是事件流的可视化视图，模型读到的是事件流的历史，工具执行器消费的是 Action 事件。

这个设计给我最大的启发是：它把"代理程序的运行过程"和"交互界面"彻底解耦了。你可以用浏览器 UI 看代理干活，也可以用命令行，甚至可以通过 API 让另一个程序订阅事件流。调试的时候，你可以把事件流导出来逐条回放，看到底是哪一步决策出了问题。这一点对开发编程代理的人来说非常关键——没有事件流的代理，出错了就是一团黑箱；有了事件流，代理的每一步都有迹可循，可观测性直接拉满。

3.2 行动接口的宽度：文件、终端、浏览器一网打尽

项目 B 在工具设计上走的是"宽覆盖"路线。它给代理配置了三类核心工具：

• 文件操作：读取、写入、编辑、目录列举，支持按路径和模糊搜索定位文件。
• 终端执行：代理可以在沙箱环境里运行 shell 命令，包括编译、测试、安装依赖。
• 浏览器操作：代理能打开页面、点击元素、填写表单、读取渲染后的 DOM。官方意图是让代理能做"需要打开浏览器才能验证"的任务，比如前端联调或者爬取页面信息。

这三大类工具合在一起，意味着代理几乎拥有了一个真实开发者工作台的全部能力。它的一个 Agent 实现甚至直接把推理过程和动作合并成一整段 Python 代码：模型生成的不是"调用某个函数"的单步指令，而是一段可以顺序执行的脚本，脚本里可以混入文件读写、shell 调用，甚至可以打印中间结果给模型自己看。这种"代码即行动"的思路，大大提高了代理执行复杂序列时的效率，因为模型不需要一轮一轮地为了一个多步操作来回切换工具，而是可以一口气写出一段完成多步操作的程序。

3.3 沙箱隔离：自治与安全之间的取舍

工具越宽，风险就越大。当代理能在终端里执行任意命令时，你怎么保证它不会把项目目录删了？不会把环境变量搞坏？不会连到外部网络干些意料之外的事情？

项目 B 的做法是把所有工具执行放进隔离的容器沙箱里。代理的终端操作、浏览器操作、甚至文件系统的初始状态，都在一个可随时销毁重建的隔离环境里进行。你给代理的任务，它在沙箱里实验、修改、验证，直到跑通了，你才把最终的改动拿回来审阅。

这里有一个特别值得注意的取舍：沙箱提高了安全性，但同时也限制了代理访问你本机环境的真实信息。代理在沙箱里跑不通某个依赖，往往是因为沙箱里没有你本地那份特殊的配置。所以项目 B 设计了多种运行模式：可以完全在本地运行（高权限高风险），也可以在容器沙箱运行（安全但环境与生产有差异）。我个人的经验是，如果只是让它做代码生成和结构化修改，本地模式问题不大；只要涉及自动化高风险的依赖安装或批量文件操作，务必切换到沙箱模式。

项目 B 的复杂度和它的野心是匹配的。它不是拿来写个函数补丁的，而是适合做"多文件重构""跨模块修改"和"需要反复验证的工程任务"的研究级工具。社区里甚至有人拿它跑单次多小时的自主开发任务，这在项目 A 的交互模式下是很难想象的。

4. 在 IDE 里落地的自主编码代理：项目 C

4.1 工具集设计：读、写、执行、搜索的权限划分

项目 C 走的是第三条路：不是让你在终端里和代理对话，而是把编程代理直接嵌进你每天都在用的编辑器里，同时兼顾"自主"和"可控"。它的工具集设计和项目 B 很不一样，B 是堆工具宽度，C 是讲权限划分。

它把工具分成几大类，每一类的触发时机都不同。读取类工具（打开文件、查看目录、搜索代码）在代理思考时自由调用；而会改变系统状态的操作（写文件、执行终端命令、安装依赖），则要在经过你授权之后才能执行。在 IDE 的交互模型里，代理每发起一个"写文件"或"执行命令"动作，界面都会弹出一个提示让你确认。

这个设计解决了一个很现实的矛盾：纯自主代理（如项目 B）效率高但风险大，纯交互代理（如项目 A）安全但每步都要人盯着。项目 C 的"分权限工具"模式，把高风险动作变成需要你确认的动作，把低风险动作留给代理自由裁量，在效率和安全感之间找到了一个非常实用的折中点。

4.2 Plan 与 Act 双模式：思考优先还是行动优先

项目 C 在工作模式上做了一个十分值得借鉴的决策：把代理分成Plan 模式和 Act 模式。

在 Plan 模式下，代理只能使用只读工具。它可以读文件、搜索、查看依赖关系，可以给出详细的分析和实施方案，但不能改任何一个文件，也不能执行任何命令。这个模式适合做任务规划和代码走查：你要做一个涉及多个文件的改造，先让代理把改动方案说清楚，你看了没问题再切换模式执行。在 Act 模式下，代理才获得全部工具权限，可以自主修改代码、跑测试、迭代验证。你可以在两种模式之间随时切换，甚至可以在 Act 模式中途切回 Plan，让代理先停下来重新分析。

为什么这个设计有效？因为大量研究表明，让模型"边想边做"很容易在上下文里累积错误决策，越到后面越容易偏离方向。而显式地隔离开"分析"和"执行"，等于在机制层面强制模型先形成方案再动手。如果说项目 A 的成功在于"把循环做短"，项目 C 的成功就在于"把思考和执行拆开"。这个模式后来被很多编程代理产品学习，现在你在很多工具里看到的"先出计划，确认后执行"，最初的架构原型就来自这类设计。

4.3 上下文瘦身：Token 预算管理与自动压缩机制

项目 C 还有一个很细节但很关键的设计：上下文管理。IDE 场景下，代理会不断读取文件、记录搜索结果，对话轮次一多，上下文窗口很快就会被撑满。项目 C 的策略是给上下文设一个预算上限，当接近上限时，它不是简单粗暴地截断最早的消息，而是自动把早期低价消息压缩成摘要：比如把五轮关于某个函数实现的讨论，浓缩成"已确定将parse_data函数重构为返回生成器"。这个摘要保留在上下文里，这样代理仍然记得结论，但省下了大量 token 空间。

在我用过的同类工具里，项目 C 的上下文管理算是最让我省心的。它还会根据当前打开的文件和选中的代码，主动把"最相关的文件"加入上下文，而不是让所有历史消息平权竞争位置。这些细节听起来不性感，但决定了代理能不能在长时间任务里保持高质量输出。很多自己拼装的 Agent 跑着跑着就"失忆"，本质就是没做过类似的上下文治理。

拆完项目 C，我最大的感受是：它证明了编程代理不需要在"全自动"和"纯手动"之间二选一。通过权限分级、模式切换和上下文压缩，一个编辑器插件也能承载相当强的自主编码能力，同时不夺走开发者的控制权。

5. 把三个项目放在解剖台上：架构本质的横向对照

5.1 控制权归属：谁在主导循环

把三个项目摆在一起看，第一个要比较的就是控制权：谁来决定代理下一步干什么。

项目 A 是人主导的协作循环，每一步行动都从用户的输入开始，模型响应后等用户确认，再进入下一步。这种模式的好处是可控性极高，缺点是自动化程度低，模型很难连续自主地推进一个大型任务。

项目 B 是代理主导的自主循环，模型拿到目标后自己规划、自己执行、自己根据观察迭代，用户主要看最终结果。好处是自动化程度高，坏处是中间过程一旦出错，排查和介入都比较费力。

项目 C 是混合主导：你在 Plan 模式里掌握决策权，切到 Act 模式后代理自己跑，你可以在关键动作处打断和授权。这个设计本质上把控制权做成了一条连续光谱，你可以按任务风险等级滑动控制点。

这个差异表面上是产品定位的不同，实际上是架构上的选择：控制权越靠模型，你对循环稳定性的要求就越高，必须有事件流或日志系统来兜底；控制权越靠人，循环越简单，但对交互设计的要求就越高。

5.2 记忆与上下文：数据从哪里来、到哪里去

第二个核心维度是代理怎么"记住"它工作的环境。

• 项目 A 的记忆是两层：短期的对话历史和长期的代码库地图。它不试图理解仓库里所有代码的细节，只维护一张符号级别的骨架图，按需加载。
• 项目 B 的记忆依托于事件流：所有行动、观察、消息都在流里，模型在任何时刻都可以回溯此前任意一步的执行结果。相当于代理有一个"完整审计记忆"，代价是上下文很容易膨胀，所以它也引入了摘要压缩策略。
• 项目 C 的记忆是"动态组装"的：根据当前任务实时决定读哪些文件、留哪些摘要，试图用最小的 token 成本维持对任务的最优理解。

三者的差异背后是一个权衡：上下文信息的完整性与经济性不可兼得。想要代理不丢上下文，就要付出 token 成本；想要省 token，就必须接受代理在对项目理解上的"盲区"。没有绝对正确的选择，只有适合场景的选择。

5.3 改动落地方式：diff 增量与全量重写之争

第三个维度是文件修改的粒度。

项目 A 强制走 diff 编辑，模型只输出变更，由程序合成最终文件。这种方式对 token 友好、diff 清晰、容易审查，但对模型的"精准编辑"能力要求高。

项目 B 因为采用"代码即行动"的模式，很多时候直接生成新的文件内容并覆盖，改动粒度可以非常大。它追求的是执行效率，一个脚本可以同时改十个文件，但结果的可审查性和精细度就要靠事后 diff 来补。

项目 C 的工具集里同时提供"整文件写入"和"局部替换"两类编辑工具，让模型按需选择。它还引入了"查找-替换"式的精确修改，当模型只需要改一个函数体时，不大费周章重写整个文件。

我的体会是，diff 增量更适合日常结对场景，因为改动小、好 review；全量重写更适合自动化重构场景，因为让模型在旧结构上打补丁反而别扭。编程代理的架构设计里，"以什么粒度落地修改"是一个影响非常大的决策，它同时牵扯上下文消耗、错误传播和审查体验。

5.4 一张表看清三种架构的取舍

这张表基本就是编程代理架构的全部内核了。你会发现，所谓"看透架构本质"，其实就是回答五个问题：谁来决策、模型怎么看仓库、改动怎么落地、执行怎么隔离、历史怎么管理。这三个项目各自交出了不同的答卷，没有标准答案，只有不同约束下的最优解。

6. 从拆解到实践：落地选型与避坑体验

6.1 场景选型：不同需求匹配不同架构

拆了架构，最终还是要落地。我给不同场景的建议是这样的：

如果你是一个人维护中小型项目，希望在日常编码里有一个"随叫随到、能改 bug、能补测试"的结对搭档，项目 A 的轻量交互模式最舒服。它安装快、心智负担小，每一次改动都能在 git 里看到，完全不需要额外的隔离措施。

如果你要做大范围重构——比如把整个项目从回调改成 async/await，或者给几十个类统一补上异常处理——项目 A 这种逐轮交互的模式会让你点到手软，这时候项目 B 的自主规划和多工具并行才是正解。它可以在沙箱里自己探索、自己改、自己跑测试，一口气推进完整任务。

如果你是重度 IDE 用户，写代码的大部分时间都花在编辑器里，那项目 C 的嵌入体验最好。选一段代码，让它先 Plan 后 Act，风险可控又不打断工作流。

还有一种常见需求是团队协作：多个开发者共享一个编程代理服务。这种情况项目 B 的事件流架构优势明显，因为事件流天然支持多人订阅和协作，代理的状态不是某一个人的私有对话。

6.2 踩过的坑：循环失控、上下文污染与权限失控

用编程代理用得越深，踩的坑也越多。我挑三个最有代表性的说一下。

第一个坑是循环失控。自主代理跑多步任务时，经常出现"反复改同一个文件但始终不满意"的死循环。根因通常是反馈信号太弱——测试没有明确报错，模型就不知道自己的改动是对是错，于是反复试。我的办法是给任务设置明确的验收条件和最大迭代步数，比如"pytest 全绿，最多改 5 轮"，代理到点不收敛就停下来向你汇报，而不是无限空转。

第二个坑是上下文污染。很多 DIY 者想让代理"看到更多"，于是把一堆文件一股脑塞进上下文。结果模型被无关信息淹没，改出各种张冠李戴的逻辑。正确的做法是向项目 A 学习：只给骨架和摘要，代理需要细节时再主动去读，而不是预先把整条街的店铺都塞给一个问路人。

第三个坑是权限失控。我给项目 B 跑过一个自动化任务，它在一个本该只读的目录里创建了十几个临时文件，还把环境变量改了，整个环境弄得一团乱。从那以后我养成了习惯：凡是会执行命令的代理场景，一律先开沙箱或至少备份工作区。权限下放要一点点来，宁可让代理多问你一次，也别让它一次把所有权限都拿到。

6.3 自己动手：用 30 行代码搭一个最小编程代理

看再多架构不如自己搭一遍。下面是我手工构造过的极简编程代理的核心逻辑，也就三十来行，能让一个模型通过工具调用完成"读文件-改文件-跑命令"的闭环。大模型服务的接入部分替换成你惯用的 SDK 即可。

import json import subprocess # 这里替换为你所选大模型服务的客户端 client = None TOOLS = [ { "type": "function", "function": { "name": "read_file", "description": "读取指定文件的全部内容", "parameters": { "type": "object", "properties": { "path": {"type": "string", "description": "文件路径"} }, "required": ["path"], }, }, }, { "type": "function", "function": { "name": "write_file", "description": "把内容写入指定文件", "parameters": { "type": "object", "properties": { "path": {"type": "string", "description": "文件路径"}, "content": {"type": "string", "description": "要写入的完整内容"}, }, "required": ["path", "content"], }, }, }, { "type": "function", "function": { "name": "run_command", "description": "执行命令行命令并返回输出", "parameters": { "type": "object", "properties": { "command": {"type": "string", "description": "要执行的命令"} }, "required": ["command"], }, }, }, ] def call_tool(name, args): if name == "read_file": with open(args["path"], "r", encoding="utf-8") as f: return f.read() if name == "write_file": with open(args["path"], "w", encoding="utf-8") as f: f.write(args["content"]) return "文件已写入" if name == "run_command": result = subprocess.run( args["command"], shell=True, capture_output=True, text=True ) return result.stdout or result.stderr def agent_loop(goal, max_steps=10): messages = [ { "role": "system", "content": f"你是一个编程代理。目标：{goal}。" "你可以调用工具推进任务，全部完成后回复'DONE'并简述改动。", } ] for _ in range(max_steps): resp = client.chat.completions.create( model="你的模型名", messages=messages, tools=TOOLS ) msg = resp.choices[0].message messages.append(msg) if not msg.tool_calls: print("代理回复：", msg.content) break for tc in msg.tool_calls: result = call_tool(tc.function.name, json.loads(tc.function.arguments)) messages.append( {"role": "tool", "tool_call_id": tc.id, "content": result} ) else: print("达到最大步数，任务可能未收敛，请检查日志。") # 示例：让代理修复 main.py 中的语法错误并跑测试 agent_loop("修复 main.py 的语法错误，并运行 python -m pytest 确认测试通过")

这个迷你代理没有仓库地图、没有沙箱、没有上下文压缩，但你跑一遍就能直观感受到 Agentic Coding 的核心机制：模型输出工具调用，宿主程序执行并返回结果，模型根据结果调整下一步。把这三段逻辑跑通之后，再看项目 A 的代码库地图、项目 B 的事件流、项目 C 的权限分级，你就知道它们各自解决的是上面这个骨架里哪一环的什么问题了。

我自己折腾完这三个项目，最大的体会是：编程代理的架构进步，很少来自某个大模型的突然变强，更多来自这些看似琐碎的工程细节——用 diff 还是整写、上下文摘不摘要、沙箱隔离到哪一层、谁来点确认键。这些决定堆叠在一起，才塑造出了一个代理"靠谱还是失控"的天壤之别。如果你也想在自己的项目里引入 Agentic Coding，不用一上来就追求最全的工具和最宽的权限，从一个小而清晰的闭环开始，把每一环反馈做扎实，再慢慢往里面加你想要的能力，这条路会比直接部署一个大而全的系统稳得多。