Doubao-Seed-1.8：ByteDance 官方 Code Agent 工具闭环工作流

一句话结论

Seed1.8 的 Code Agent 核心不是一次生成代码，而是“模型选择工具 → 执行工具 → 把结果回填 → 再次推理”的可循环闭环。

适用场景

• 适合的任务：创建/编辑文件、运行测试、代码搜索、调用本地计算或 HTTP 工具的多轮工程任务。

• 不适合的任务：未经沙箱隔离就把任意 shell 暴露给生产模型，或只需要一次短文本回答的低延迟任务。

• 适用的模型版本：官方 notebook 示例使用 Seed1.8；样例端点包含 doubao-seed-1-8-251215，实际可用端点需以火山引擎控制台为准。

• 适用的客户端、Agent 或 API：火山引擎 Ark Chat API；Python requests 示例和 OpenAI 风格消息结构。

• 推荐的推理档位和参数：官方 cookbook 说明使用 medium reasoning effort；样例请求包含 max_tokens=4096、top_p=0.9、temperature=0.0。生产环境应只调整 temperature 或 top_p 其中一个，并记录实际模型 ID。

可直接使用的内容

以下是按官方 notebook 抽取并补上安全边界的可执行工作流骨架；工具 schema 的字段名可直接作为起点，具体 API 参数需按当前 Ark 版本核对。

初始化：
1. 设置 ARK_API_KEY 和 ARK_MODEL_ENDPOINT。
2. 使用 https://ark.cn-beijing.volces.com/api/v3/chat/completions。
3. 注册最小工具集：
   - str_replace_editor(command, path, file_text, old_str, new_str, insert_line, view_range)
   - execute_bash(command)
   - finish()
4. 所有工具在隔离 workspace 中运行；路径白名单、命令白名单和超时必须由宿主校验。

循环：
1. 发送 system/user 消息和 JSON Schema 工具列表。
2. 若模型返回 tool_calls，严格校验函数名和参数，再执行一个或多个允许的工具。
3. 把每个工具的结果以 tool 消息追加到对话，保留原 tool_call_id。
4. 再次请求模型，直到返回最终答案或 finish；限制最大轮数，超过则输出可诊断错误。
5. 保存每轮模型 ID、reasoning/content、工具参数、退出原因和 token usage。

测试/工作流步骤

1. 先用官方示例任务创建 test.py，验证模型能产生 str_replace_editor 的合法 JSON 参数。

2. 执行工具后把文件状态回填，再让模型读取、修改并运行测试，观察是否完成至少两轮。

3. 注入一个工具失败结果，确认模型能停止或改用备用工具，而不是无限重试。

4. 把 finish 作为显式终止工具，分别测单轮和多轮任务的完成率、工具参数合法率、轮数和成本。

原始证据与数据

• 官方 notebook 将 Code Agent 描述为 medium reasoning effort，并明确采用 function tools、第二次 completion 合并工具输出的 closed loop。

• 官方列出的能力包含 tool use、closed loop、single/multi-turn inference、minimal retries/fallbacks/safe defaults。

• 示例环境变量是 ARK_MODEL_ENDPOINT="doubao-seed-1-8-251215"，base URL 为 https://ark.cn-beijing.volces.com/api/v3；示例请求体含 max_tokens=4096、top_p=0.9、temperature=0.0、reasoning_effort="medium"。

• notebook 的一次示例输出返回 finish_reason=tool_calls，并报告 completion_tokens=156、prompt_tokens=1403、reasoning_tokens=111；这是官方样例运行产物，不是通用平均值。

• 官方仓库同时提供 Search、MCP、Multimodal Search、Thinking with Images、Video 等 cookbook 入口，可将同一闭环扩展到其他工具。

适用边界

• 仓库样例使用的端点名和返回 model ID 可能随服务更新；必须保存实际响应中的 model 字段，不能只记录环境变量。

• execute_bash 和文件编辑工具拥有高风险副作用，真实部署必须做沙箱、路径/命令白名单和人工确认。

• notebook 展示流程和示例输出，没有给出跨任务成功率或统一 benchmark；不要把一次工具调用成功当成工程可靠性证明。

• 工具返回结果回填格式、reasoning 字段和多轮消息顺序必须保持 API 协议要求，否则闭环可能失效。

来源摘录或观察（仅做合规短引）

官方 notebook 的关键设计是“model automatically select and call local functions”，随后把工具结果回传给模型形成闭环；本文将该结构改写为安全可执行清单。