这次我们要聊的，是 Coding Agent 赛道上一个很特别的项目：Shelley。名字取自诗人雪莱，但这个项目跟写诗没关系，它的定位是“一个能参与真实开发工作的 AI 编程智能体”。如果你关心 AI Coding Agent 最近半年到底进化到了什么程度，或者正在对比 Cursor、Devin、开源 Coding Agent 方案，那 Shelley 值得你花十分钟了解一下。
先说结论：Coding Agent 这类工具已经不是“聊天补全代码”的玩具了。从 2026 年年初到现在，AI 编程智能体的重点早就从“单文件补全”转移到了“多文件仓库级任务闭环”：自己读仓库、自己定位问题、自己写代码、自己跑测试、自己修 Bug。Shelley 属于这个方向的典型形态，它的核心卖点不是某个模型有多强，而是把“让 AI 自己干完一个小功能”这件事做得更接近工程化。本文会从核心能力、适用场景、环境准备、部署启动、功能测试、接口批量任务、性能观察和问题排查几条线展开，帮你判断这类工具值不值得接进自己的工作流。
先说清楚这篇文章的边界：由于 Shelley 的公开材料目前还在快速迭代阶段，很多参数和实现细节没有最终定稿，所以文章中凡是涉及具体数字的地方，我会明确标注“需以实际环境测试为准”。但整体的部署思路、功能验证方法和工程化建议，都是 Coding Agent 类项目的通用经验，可以直接复用。
1. Shelley Coding Agent 核心能力速览
先把规格放在最前面。基于当前公开资料和 Coding Agent 类项目的常见能力边界，整理成下表：
| 能力项 | 说明 |
|---|---|
| 项目类型 | AI 编程智能体 / Coding Agent |
| 核心功能 | 代码理解、代码生成、代码重构、Bug 定位与修复、测试生成、多文件仓库级任务 |
| 交互方式 | 对话式自然语言交互，支持任务拆解和分步执行 |
| 是否支持仓库级操作 | 从产品定位看支持，可读取多文件并跨文件修改，具体粒度需实测 |
| 是否支持批量任务 | 通常通过 CLI / API 方式支持，可串联多个任务，具体需看版本实现 |
| 是否开放 API | 大概率支持，Coding Agent 类工具普遍提供 HTTP 或 SDK 接口，具体路径需查看项目文档 |
| 硬件门槛 | 若接入云端大模型，本地仅需普通开发机；若本地部署模型，需按模型参数量准备显存或内存 |
| 推荐硬件 | 本地推理建议 24G 以上显存或纯 CPU + 大内存跑小模型；云端 API 方式无特殊硬件要求 |
| 支持操作系统 | Windows / macOS / Linux 取决于运行环境，Node 与 Python 项目通常三端可跑 |
| 启动方式 | CLI 命令启动 / Web 界面 / IDE 插件 / 容器部署 |
| 外部依赖 | Git 环境、Node.js 或 Python、代码仓库权限、大模型 API Key 或本地模型服务 |
| 适合场景 | 个人开发者自动化重构、团队代码审查辅助、测试用例批量生成、仓库级 Bug 排查 |
注意，这张表里有几个“需实测”项，是因为 Coding Agent 类项目在不同版本里的能力差异极大。有的版本只支持单文件编辑，有的已经支持整个 PR 的自动创建。拿到 Shelley 的实际版本后，第一个做的工作就应该是把这几个“需实测”项全部过一遍，确认它的能力边界到底在哪里。
2. 适用场景与使用边界
2.1 适合谁用
Shelley 这类 Coding Agent 最适合下面几类人：
第一类是“日常写业务代码但被重复劳动拖累”的开发者。比如增删改查接口、写单元测试、补类型定义、做中英文文案替换，这些任务规则清晰、重复度高，让 Agent 来做是性价比最高的。
第二类是“刚接手一个旧仓库，不知道代码结构”的开发者。Coding Agent 可以快速读仓库、生成目录说明、标注模块依赖关系，省去自己从头翻源码的时间。
第三类是“需要批量处理代码任务”的团队。比如全仓库统一改日志格式、为多个接口补参数校验、为一批组件生成文档，这些任务如果用人肉搜索加替换很容易出错，用 Agent 脚本批量处理更稳定。
2.2 不适合什么场景
有几类场景现阶段不建议硬用：
- 高复杂度系统架构设计。Coding Agent 可以帮你改代码，但让它设计一套微服务拆分方案并保证正确性，现阶段风险仍然很高。
- 强业务规则领域。涉及复杂金融计算、医疗合规逻辑、安全权限判断的地方，AI 生成的代码必须人工逐行审查，不宜直接信任。
- 没有测试覆盖的祖传巨石仓库。Agent 改代码后如果无法通过自动化测试验证，很容易引入隐性回归。
2.3 使用边界与合规提醒
这是必须强调的：Coding Agent 在执行任务时，本质上是“自动读取代码库并自动修改文件”。这意味着它会接触你的源码、配置、硬编码密钥、潜在的用户数据。使用时要重点确认：
- 仓库权限最小化，只给 Agent 它真正需要的分支和目录权限。
- 不要把生产环境密钥、数据库连接串直接写进配置并被 Agent 读取。
- 修改代码前先确保仓库处于 Git 版本控制之下，方便回滚。
- 涉及开源代码时，确认 Agent 生成的代码是否存在许可证冲突。
- 如果团队代码涉及商业机密，优先使用私有化部署模型，不要将代码发送到外部 API 服务。
3. Shelley 本地部署与前置环境准备
3.1 运行模式先选好
Coding Agent 类工具的部署方式，基本分为三档：
第一档：云端 API 模式。本地只跑一个客户端（CLI / IDE 插件），真正的大模型推理在云端完成。门槛最低，普通开发机即可，但需要 API Key，且代码会离开本地环境。
第二档：本地模型直连模式。下载开源模型权重，在本地跑推理服务（比如通过 vLLM、Ollama 或 llama.cpp 提供 OpenAI 兼容接口），Shelley 客户端连接本地模型地址。适合对数据敏感、或需要离线开发的团队。
第三档：容器化部署模式。把 Agent 服务、模型推理服务、任务队列一起打包成 Docker Compose 或 Kubernetes 工作负载。适合团队内多人共用一个 Agent 服务。
3.2 通用环境检查清单
不管选哪种模式，基础环境建议按下面的清单逐项确认：
| 检查项 | 建议要求 | 说明 |
|---|---|---|
| 操作系统 | Windows 10/11、macOS 12+、Ubuntu 20.04+ | 三端都行，但注意命令行兼容性 |
| Git | 2.30 以上 | Agent 需要读取仓库变更、生成 diff |
| Node.js | 18 或 20 LTS | 多数 Coding Agent CLI 基于 Node 生态 |
| Python | 3.10 以上 | 如果需要写脚本或跑本地推理框架 |
| 包管理器 | npm / pnpm / uv 按项目要求 | 安装项目依赖用 |
| API Key | OpenAI 兼容接口 Key 或本地模型服务地址 | 必填，否则无法启动推理 |
| 磁盘空间 | 视模型而定，本地大模型预留 20G+ | 模型文件占大头 |
| 端口 | 默认服务端口需要空闲 | 常见 3000、8000、8080，注意冲突 |
安装依赖时，最常见的坑是 Node 版本不匹配。很多 Coding Agent 工具对 Node 版本有要求，建议先跑node -v确认版本，再决定用 nvm 切换版本还是直接升级。这里给一套通用安装流程，实际命令以 Shelley 官方文档为准：
# 1. 确认基础环境 node -v npm -v git --version python3 --version # 2. 克隆项目（示例，路径需替换为实际仓库地址） git clone https://github.com/example/shelley.git cd shelley # 3. 安装依赖 npm install # 如果项目提供 Python 侧依赖，则执行 pip install -r requirements.txt安装完成后，通常需要配置一个环境变量文件。Coding Agent 普遍支持.env方式配置模型接口：
# .env 示例，实际变量名以项目文档为准 MODEL_PROVIDER=openai-compatible MODEL_API_KEY=sk-xxxxxxxx MODEL_BASE_URL=https://api.example.com/v1 MODEL_NAME=gpt-4o WORKSPACE_DIR=/path/to/your/repo再次强调：MODEL_BASE_URL可以是云端 API 地址，也可以是本地模型的 OpenAI 兼容服务地址，取决于你选哪种运行模式。如果本地启动模型服务，通常用http://127.0.0.1:8000/v1这样的地址。
4. Shelley 启动方式与服务访问
4.1 CLI 命令行启动
Coding Agent 最常见的启动方式是 CLI。启动后一般会进入一个交互式终端界面，你可以直接输入自然语言指令：
# 启动 CLI 交互模式，实际命令以项目 README 为准 npx shelley --workspace ./my-repo # 或者源码方式启动 node src/cli.js --workspace ./my-repo如果启动过程中提示缺少模型配置，检查.env文件是否被正确加载。CLI 启动成功后，界面通常会显示当前工作目录和已连接模型名称，之后就能输入类似“帮我把src/utils.js里的parseTime函数改成支持时区参数”的指令。
4.2 Web 界面启动
有些 Coding Agent 会附带 Web 管理界面，方便可视化查看任务状态。启动方式通常类似：
npm run web # 或 python app.py --host 127.0.0.1 --port 8080启动后浏览器访问http://127.0.0.1:8080，可以在页面上选择仓库目录、输入任务、查看 Agent 执行日志和文件变更列表。Web 界面的价值在于任务过程可视化：用户可以清楚地看到 Agent 在哪个文件上卡住、执行了哪条命令、为什么报错。
4.3 端口冲突与进程管理
启动服务时如果提示port is already in use，按下面的方式处理：
# 查找占用端口的进程 lsof -i :8080 # 或在 Windows 上 netstat -ano | findstr :8080 # 杀掉占用进程（注意确认进程身份） kill -9 <PID>也可以直接指定一个空闲端口启动，避免影响正在运行的本地服务。日常使用建议用一个固定的端口跑 Agent 服务，并把启动命令写进脚本，方便反复启动。
4.4 第一次启动如何验证成功
启动成功的判断标准不是“不报错”，而是“能完成一次完整的对话式任务”。建议第一次用一个最小仓库测试：新建一个临时文件夹，放一个简单的index.js，然后让 Agent 读取并改写它。如果 Agent 能正确描述文件内容并生成修改后的 diff，说明从模型接口到代码编辑链路已经全部打通。
5. Shelley 功能测试与效果验证
拿到一个 Coding Agent 后，不建议立刻在正式仓库上跑大任务。先按下面的维度做一轮功能测试，确定它的能力和稳定性边界。
5.1 测试一：代码理解能力
目的：确认 Agent 能否正确阅读指定文件并提取关键信息。
输入示例：
请读取 src/config.js，说明这个文件导出了哪些配置项，以及每个配置项的默认值。预期结果：Agent 返回文件结构说明、配置项列表和默认值。判断成功的标准是：它没有额外修改文件，回答内容与源码一致。
失败排查：
- 如果 Agent 说找不到文件，检查工作目录是否指向正确仓库路径。
- 如果回答内容与源码明显不符，说明模型上下文或检索环节有问题，考虑更换模型或检查索引缓存。
5.2 测试二：单文件代码修改
目的：确认 Agent 能修改代码并生成正确 diff。
输入示例：
把 src/utils.js 中的 formatDate 函数改为支持 "YYYY-MM-DD HH:mm:ss" 格式。预期结果：Agent 读取函数、修改实现、输出变更后的代码片段。判断成功标准：修改后的代码在语法上没有明显错误，并且保留了原有逻辑的兼容性。
建议一直开着 Git 的状态查看变更：
git diff一旦发现 Agent 的修改影响范围超出预期（比如改到了无关函数），立刻git checkout -- <file>回滚，并调整指令约束范围。
5.3 测试三：多文件仓库级任务
目的：确认 Agent 是否能跨文件完成一个完整功能。
输入示例：
在 src/api/ 目录下新增一个 rate_limit.py 模块，实现基于 Redis 的接口限流，并在现有 FastAPI 应用的 main.py 中注册该中间件。预期结果：Agent 创建新文件、修改路由注册代码，最后给出变更摘要。判断成功标准：一是所有变更都能通过git diff查看；二是变更内容逻辑自洽；三是如果仓库里有测试，能跑通至少一轮。
这轮测试最能暴露 Coding Agent 的真实水平。很多 Agent 在单文件修改上表现良好，但一跨到“新增文件 + 修改入口文件 + 处理依赖导入”三个动作就乱套。测试时重点关注依赖导入、参数传递、函数命名一致性。
5.4 测试四：测试用例生成
目的：确认 Agent 能否为已有代码补充测试。
输入示例：
为 src/calculator.py 中的所有公开函数生成 pytest 测试用例，覆盖正常输入、边界输入和异常输入。预期结果：Agent 在 tests/ 目录下生成测试文件，内容覆盖多种输入场景，并尝试执行测试。判断成功标准：测试文件语法正确，测试可以运行，运行结果可以区分通过和失败。
这里要特别关注 Agent 是否真的执行了测试命令，还是只生成了文件就说“完成”。一个成熟的 Coding Agent 应该能够运行pytest或npm test并读取输出结果。
5.5 测试五：Bug 修复闭环
目的：确认 Agent 能否通过报错信息定位问题并修复。
输入示例：
运行 npm test 后出现以下报错：TypeError: Cannot read properties of undefined (reading 'map')。请定位问题并修复。预期结果：Agent 搜索相关代码、定位变量可能为 undefined 的位置、提出修复方案并应用修改。判断成功标准：修改后再次运行测试，报错消失或是出现新的预期报错。
Bug 修复闭环是目前 Coding Agent 类工具最有价值、也最难做好的一环。如果 Shelley 在这个环节表现稳定，说明它已经具备“定位-修复-验证”的基本工程能力。
5.6 功能测试记录表
建议在测试过程中记录下表，方便后续对比版本变化：
| 测试维度 | 是否通过 | 耗时 | 备注 |
|---|---|---|---|
| 代码理解 | 待测 | 待测 | 重点看长文件理解准确度 |
| 单文件修改 | 待测 | 待测 | 重点看 diff 是否最小化 |
| 多文件任务 | 待测 | 待测 | 重点看跨文件一致性 |
| 测试生成 | 待测 | 待测 | 重点看测试是否真实可运行 |
| Bug 修复闭环 | 待测 | 待测 | 重点看是否执行验证命令 |
6. Shelley 接口 API 与批量任务
Coding Agent 如果只能人在终端里敲指令，价值会小很多。真正工程化的用法是把 Agent 能力暴露成 API，接入到 CI/CD、代码托管平台或内部工具链中。下面给一套通用化的接口调用思路，具体参数名和路径需以 Shelley 项目文档为准。
6.1 启动 API 服务模式
通常可以在启动命令里加一个--api参数，或在配置文件里启用 server 模式：
# 示例：以 API 服务模式启动 node src/cli.js --workspace ./my-repo --api --port 8080启动后，本地会监听 8080 端口，等待外部请求。此时可以先请求一个健康检查接口：
curl http://127.0.0.1:8080/health如果返回{"status":"ok"}之类的响应，说明 API 服务已经在正常工作。
6.2 HTTP 调用示例
假设接口约定是：POST /api/tasks创建任务，GET /api/tasks/{id}查询任务状态。可以这样写调用脚本：
# 创建任务 curl -X POST http://127.0.0.1:8080/api/tasks \ -H "Content-Type: application/json" \ -d '{ "instruction": "为 src/utils.js 中的 debounce 函数补充 JSDoc 注释", "workspace": "/path/to/repo", "auto_commit": false }'返回结果会包含任务 ID，然后通过任务 ID 轮询状态：
curl http://127.0.0.1:8080/api/tasks/task_123456如果项目提供的不是 HTTP API，而是 Python SDK 或 Node SDK，调用方式类似，只是把 HTTP 请求换成 SDK 方法，思路完全一致。
6.3 批量任务设计
批量任务的核心思路是把“人工一条条敲指令”变成“脚本循环发请求”。服务端队列会按顺序处理任务，客户端负责提交任务和收集结果。
import requests import time import json BASE_URL = "http://127.0.0.1:8080" def create_task(instruction: str) -> str: resp = requests.post( f"{BASE_URL}/api/tasks", json={ "instruction": instruction, "workspace": "/path/to/repo", "auto_commit": False, }, timeout=30, ) resp.raise_for_status() return resp.json()["task_id"] def wait_for_task(task_id: str, timeout: int = 600) -> dict: start = time.time() while time.time() - start < timeout: resp = requests.get(f"{BASE_URL}/api/tasks/{task_id}", timeout=30) data = resp.json() if data["status"] in ("completed", "failed"): return data time.sleep(5) raise TimeoutError(f"task {task_id} timeout") # 批量提交 tasks = [ "修复 src/parser.py 中所有 TODO 注释标记的未实现分支", "为 src/models.py 中的所有数据类补充 __repr__ 方法", "将 src/config.py 中的硬编码超时时间提取为环境变量配置", ] task_ids = [create_task(t) for t in tasks] for tid in task_ids: result = wait_for_task(tid) print(tid, result["status"]) print(json.dumps(result, ensure_ascii=False, indent=2))批量任务最怕的是“某个任务卡死，占用队列，后面任务全部阻塞”。解决方案通常是带上超时时间和失败重试：
- 单任务超时：建议 5 到 10 分钟，超过则标记为 failed。
- 失败重试：同一个任务最多重试 2 次，避免无限循环。
- 输出隔离：每个任务的结果文件和代码变更都写入独立目录，方便定位。
- 日志记录：把每个任务创建时间、开始时间、结束时间、状态变化写进日志表。
6.4 接入 CI/CD 的思路
如果把 Shelley 接入 CI，一个典型场景是 Pull Request 自动审查：
# GitHub Actions 示例，实际参数需替换 name: shelley-review on: pull_request: types: [opened, synchronize] jobs: review: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - name: Run Shelley Review run: | shelley review \ --base ${{ github.event.pull_request.base.sha }} \ --head ${{ github.event.pull_request.head.sha }} \ --comment-mode github env: MODEL_API_KEY: ${{ secrets.MODEL_API_KEY }}注意一点：让 Agent 直接在 CI 中自动创建提交、自动 push 代码，属于高风险配置。建议第一阶段只让 Agent 输出 review 意见和 diff 建议，由人类决定是否合并。等稳定运行一段时间后，再考虑放开自动修复合并的权限。
7. 资源占用与性能观察
Coding Agent 的资源占用，和传统模型推理有一点不同：它不仅是“跑一次推理”，而是一个持续运行的工程流程。整体资源消耗主要分三个部分：基础服务、模型推理、任务执行过程。
7.1 基础服务占用
CLI 或 Web 服务本身占用很低，几百 MB 内存以内。真正的大头是本地模型推理。如果用云端 API，本地内存占用基本可以忽略；如果本地部署 7B 参数模型，量化后大概需要 8G 到 12G 内存或显存；如果部署 70B 级别模型，通常需要多卡或纯 CPU + 大内存配置。具体数字需以本地模型实际版本为准。
7.2 显存与内存观察方法
运行任务时，重点观察两个层面：
一是模型服务进程的资源占用。以 Ollama 或 vLLM 为例，可以通过nvidia-smi观察 GPU 显存占用：
nvidia-smi二是 Agent 工作台本身的资源占用。当 Agent 在读取大仓库目录、生成 diff 或运行测试命令时，可能会短暂出现 CPU 和内存升高，这是正常的。
如果出现显存或内存不足，常见表现是响应速度明显变慢、任务中途报错、模型服务直接崩掉。降低消耗的方向包括：缩小工作目录范围、减少同时打开的文件数量、切换小模型、降低并发任务数。
7.3 影响响应速度的因素
Coding Agent 的单次任务耗时，通常取决于几个变量：
- 仓库代码量：仓库越大，Agent 需要花费越多时间做仓库遍历和内容检索。
- 上下文窗口：长上下文模型可以一次性读取更多文件，减少多轮交互次数。
- 任务复杂度：改一个函数和跨 5 个文件完成新功能，耗时差距是数量级级别的。
- 模型推理速度：本地小模型速度快但效果一般，云端大模型效果好但网络延迟高。
- 是否运行验证命令：Agent 跑单测和静态检查会显著增加任务总时长。
7.4 如何提升性能
- 将 Agent 的工作目录精确到子模块，不要让它在整个 monorepo 里漫游。
- 在任务指令中限定文件路径和函数名，减少 Agent 搜索空间。
- 给 Agent 配好
.gitignore，避免它读取 node_modules、dist 等无关目录。 - 批量任务时控制并发，通常 1 到 2 个并发足够，避免模型服务和磁盘 IO 过载。
- 长时间批量任务，建议加上断点续跑机制，避免一个任务中断导致全部重来。
8. Shelley 常见问题与排查方法
Coding Agent 的排查思路和普通程序不完全一样，因为中间多了一层“模型行为的不确定性”。同一个问题可能由配置、环境、模型三种原因导致。下面的排查表可以作为通用参考。
| 问题现象 | 可能原因 | 排查方式 | 解决方案 |
|---|---|---|---|
| 启动后提示缺少 API Key | 环境变量未加载 | 检查.env文件和 shell 环境变量 | 确认变量名正确、文件路径正确后重启 |
| 模型接口报 401 鉴权失败 | API Key 无效或已过期 | 用 curl 直接请求模型接口验证 Key | 更换有效 Key，或确认接口地址和模型名匹配 |
| Agent 不能读取仓库文件 | 工作目录指向错误 | 打印当前工作目录，确认路径包含目标仓库 | 用绝对路径或确认目录拼写 |
| 修改内容没有生效到文件 | Agent 只输出了建议但没有写文件 | 查看任务日志中是否有 write_file 动作 | 重新发起指令，明确要求“直接修改文件” |
| 生成的代码重复定义函数 | 上下文窗口截断了较早内容 | 查看 Agent 的会话历史，确认它是否遗漏了既有代码 | 缩短仓库扫描范围，或让 Agent 先读取相关文件再修改 |
| 任务进行到一半停止 | 上下文超限或单步超时 | 查看任务日志尾部，确认是否有 timeout 记录 | 加大超时时间，或把大任务拆成多个小任务 |
| 显存不足或内存飙升 | 本地模型推理压力大 | nvidia-smi 观察显存占用 | 更换小模型、减小批量大小、增加系统内存 |
| 端口冲突无法访问 | 端口被其他进程占用 | lsof -i :端口或netstat查找占用 | 更换端口或关闭占用进程 |
| Agent 修改了无关文件 | 指令范围过大，模型自主性过强 | git diff 查看变更范围 | 重新精确描述指令，限制文件路径 |
| API 批量任务卡住不返回 | 队列阻塞或单任务超时 | 查看队列状态和任务日志 | 杀掉卡死任务，增加单任务超时和重试机制 |
| 生成代码在 CI 中报错 | Agent 未实际执行验证命令 | 查看 Agent 日志中是否包含 build/test 命令 | 指令中明确要求“修改后必须运行测试验证” |
排查时的核心原则是：先看日志，再查配置，最后怀疑模型。不要一上来就觉得是模型能力不行，很多看似“模型太笨”的问题，实际上是环境变量没配置、工作目录选错、或者 Agent 根本没有足够的权限写文件。
9. Coding Agent 最佳实践与工程化建议
9.1 第一次接触，先从最小仓库开始
不要拿生产仓库做首次测试。新建一个空仓库，放入两三个简单的源码文件，跑完全部功能测试之后再上真实项目。这样可以快速判断 Shelley 的行为风格，同时避免意外改动重要代码。
9.2 必须保留 Git 基线
在每次 Agent 任务启动前，确保仓库处于干净状态：
git status git diff干净基线的好处是：Agent 跑完之后，git diff能清晰展示所有变更，如果有问题，一条git checkout .就能回滚。建议不要给 Agent 配置自动提交，全部由人工审核后再提交。
9.3 任务指令写得越具体，结果越可控
对比下面两条指令：
帮我把登录模块优化一下。在 src/auth/login.ts 中，将当前基于 session 的登录态改为基于 JWT 的登录态。要求：保留现有 API 返回值结构，新增 refreshToken 字段，更新类型定义，并补充 jwt 相关依赖到 package.json。第二条指令让 Agent 知道要改哪个文件、改成什么形式、保留什么、新增什么。Coding Agent 不是读心术，指令里的每个约束都能显著降低误改概率。
9.4 不要让 Agent 单独接触生产环境
即使是成熟的 Coding Agent，自动修改生产代码的风险依然很高。建议的接入方式是“Agent 修改，人类审核，CI 把关”，把 Agent 定位为高级辅助，而不是无人值守的自动提交器。
9.5 建立任务日志和结果归档
批量任务一定要做结果归档。推荐按下面的目录结构管理：
outputs/ 2026-08-01/ task-001/ log.txt # Agent 执行日志 diff.patch # 代码变更补丁 result.md # 任务结果说明 task-002/ ...日志和补丁分开保存，方便出问题时定位。如果某个任务失败，直接读取log.txt就能知道是模型报错、命令失败还是超时。
9.6 涉及代码版权和许可证时要谨慎
Coding Agent 的训练数据和生成内容可能涉及开源许可证问题。在商业项目中使用 Agent 生成的代码，建议走团队内部的代码合规审查流程，尤其是大规模引用了既有开源项目的场景。不要把 Agent 生成的代码当作完全独立原创来对待。
10. 总结与下一步
这里不写“未来的无限可能”之类的空话，只说实际结论：Shelley 这类 Coding Agent 代表了 AI 编程从“对话补全”走向“工程自治”的明确方向，它的价值取决于三件事：模型推理能力、仓库上下文处理能力、以及执行任务时的稳定性。
最先应该验证的功能不是花哨的“自动创建 PR”，而是最基础的“读取文件、改代码、跑测试、回报结果”闭环。如果这个闭环都走不通，其他功能都不可信；如果走通了，再逐步放开多文件任务、批量任务和 CI 集成。
最容易踩的坑：一是工作目录选错导致 Agent 读不到文件；二是 API Key 配置错误导致所有任务一直 401；三是不给指令加边界，让 Agent 在无关文件上自由发挥；四是不做日志归档，任务一多就失控。这四个坑，每一个都值得你在真正落地前提前做好预案。
下一步建议这样规划：先用一周时间，在临时仓库里跑通全部功能测试；然后把 Shelley 接到自己最熟悉、覆盖最完整的那个仓库上，从低风险的“补注释、补测试、做重构”开始；等拿到足够多的成功案例后，再考虑把它接入 CI 流程，做自动审查和批量代码变更。
如果你已经在用 Coding Agent，欢迎把你实际验证过的配置方式、模型组合和踩坑经验分享出来，这类工具的成熟速度远超我们想象。先跑一轮最小测试，比看一百篇介绍都有用。
