54 lines
9.2 KiB
JSON
54 lines
9.2 KiB
JSON
{
|
|
"version": "s02",
|
|
"decisions": [
|
|
{
|
|
"id": "four-tools-not-twenty",
|
|
"title": "Why Exactly Four Tools",
|
|
"description": "The four tools are bash, read_file, write_file, and edit_file. Together they cover roughly 95% of coding tasks. Bash handles execution and arbitrary commands. Read_file provides precise file reading with line numbers. Write_file creates or overwrites files. Edit_file does surgical string replacement. More tools would increase the model's cognitive load -- it has to decide which tool to use, and more options means more chances of picking the wrong one. Fewer tools also means fewer tool schemas to maintain and fewer edge cases to handle.",
|
|
"alternatives": "We could add specialized tools (list_directory, search_files, http_request), and later versions do. But at this stage, bash already covers those use cases. The split from v0's single tool to v1's four tools is specifically about giving the model structured I/O for file operations, where bash's quoting and escaping often trips up the model.",
|
|
"zh": {
|
|
"title": "为什么恰好四个工具",
|
|
"description": "四个工具分别是 bash、read_file、write_file 和 edit_file，覆盖了大约 95% 的编程任务。Bash 处理执行和任意命令；read_file 提供带行号的精确文件读取；write_file 创建或覆盖文件；edit_file 做精确的字符串替换。工具越多，模型的认知负担越重——它必须在更多选项中做选择，选错的概率也随之增加。更少的工具也意味着更少的 schema 需要维护、更少的边界情况需要处理。",
|
|
"alternatives": "我们可以添加专用工具（list_directory、search_files、http_request），后续版本确实这么做了。但在当前阶段，bash 已经覆盖了这些用例。从 v0 的单一工具拆分为 v1 的四个工具，专门是为了给模型提供结构化的文件 I/O 操作，因为 bash 的引号和转义经常让模型出错。"
|
|
},
|
|
"ja": {
|
|
"title": "なぜ正確に4つのツールなのか",
|
|
"description": "4つのツールは bash、read_file、write_file、edit_file です。これらでコーディングタスクの約95%をカバーします。Bash は実行と任意のコマンドを処理し、read_file は行番号付きの正確なファイル読み取りを提供し、write_file はファイルの作成・上書きを行い、edit_file は外科的な文字列置換を行います。ツールが増えるとモデルの認知負荷が増大し、どのツールを使うかの判断でミスが増えます。ツールが少ないことは、メンテナンスすべきスキーマとエッジケースの削減も意味します。",
|
|
"alternatives": "専用ツール（list_directory、search_files、http_request）を追加することもでき、後のバージョンではそうしています。しかしこの段階では bash が既にそれらのユースケースをカバーしています。v0 の単一ツールから v1 の4つのツールへの分割は、特にファイル操作に構造化された I/O を提供するためです。bash のクォーティングとエスケープはモデルを頻繁につまずかせるからです。"
|
|
}
|
|
},
|
|
{
|
|
"id": "model-as-agent",
|
|
"title": "The Model IS the Agent",
|
|
"description": "The core agent loop is trivially simple: while True, call the LLM, if it returns tool_use blocks then execute them and feed results back, if it returns only text then stop. There is no router, no decision tree, no workflow engine. The model itself decides what to do, when to stop, and how to recover from errors. The code is just plumbing that connects the model to tools. This is a philosophical stance: agent behavior emerges from the model, not from the framework.",
|
|
"alternatives": "Many agent frameworks add elaborate orchestration layers: ReAct loops with explicit Thought/Action/Observation parsing, LangChain-style chains, AutoGPT-style goal decomposition. These frameworks assume the model needs scaffolding to behave as an agent. Our approach assumes the model already knows how to be an agent -- it just needs tools to act on the world.",
|
|
"zh": {
|
|
"title": "模型本身就是代理",
|
|
"description": "核心 agent 循环极其简单：不断调用 LLM，如果返回 tool_use 块就执行并回传结果，如果只返回文本就停止。没有路由器，没有决策树，没有工作流引擎。模型自己决定做什么、何时停止、如何从错误中恢复。代码只是连接模型和工具的管道。这是一种设计哲学：agent 行为从模型中涌现，而非由框架定义。",
|
|
"alternatives": "许多 agent 框架添加了复杂的编排层：带有显式 Thought/Action/Observation 解析的 ReAct 循环、LangChain 风格的链、AutoGPT 风格的目标分解。这些框架假设模型需要脚手架才能作为 agent 运行。我们的方法假设模型已经知道如何成为 agent——它只需要工具来作用于世界。"
|
|
},
|
|
"ja": {
|
|
"title": "モデルそのものがエージェント",
|
|
"description": "コアのエージェントループは極めてシンプルです：LLM を呼び出し続け、tool_use ブロックが返されればそれを実行して結果をフィードバックし、テキストのみが返されれば停止します。ルーターも決定木もワークフローエンジンもありません。モデル自体が何をすべきか、いつ停止するか、エラーからどう回復するかを決定します。コードはモデルとツールを接続する配管に過ぎません。これは設計思想です：エージェントの振る舞いはフレームワークではなくモデルから創発するものです。",
|
|
"alternatives": "多くのエージェントフレームワークは精巧なオーケストレーション層を追加します：明示的な Thought/Action/Observation パースを持つ ReAct ループ、LangChain スタイルのチェーン、AutoGPT スタイルの目標分解。これらのフレームワークはモデルがエージェントとして振る舞うためにスキャフォールディングが必要だと仮定しています。我々のアプローチはモデルが既にエージェントの振る舞い方を知っていると仮定します——必要なのは世界に作用するためのツールだけです。"
|
|
}
|
|
},
|
|
{
|
|
"id": "explicit-tool-schemas",
|
|
"title": "JSON Schemas for Every Tool",
|
|
"description": "Each tool defines a strict JSON schema for its input parameters. For example, edit_file requires old_string and new_string as exact strings, not regex patterns. This eliminates an entire class of bugs: the model can't pass malformed input because the API validates against the schema before execution. It also makes the model's intent unambiguous -- when it calls edit_file with specific strings, there's no parsing ambiguity about what it wants to change.",
|
|
"alternatives": "Some agent systems let the model output free-form text that gets parsed with regex or heuristics (e.g., extracting code from markdown blocks). This is fragile -- the model might format output slightly differently and break the parser. JSON schemas trade flexibility for reliability.",
|
|
"zh": {
|
|
"title": "每个工具都有 JSON Schema",
|
|
"description": "每个工具都为输入参数定义了严格的 JSON schema。例如，edit_file 要求 old_string 和 new_string 是精确的字符串，而非正则表达式。这消除了一整类错误：模型无法传递格式错误的输入，因为 API 会在执行前校验 schema。这也使模型的意图变得明确——当它用特定字符串调用 edit_file 时，不存在关于它想修改什么的解析歧义。",
|
|
"alternatives": "一些 agent 系统让模型输出自由格式的文本，然后用正则表达式或启发式方法解析（例如从 markdown 块中提取代码）。这很脆弱——模型可能稍微改变输出格式就会破坏解析器。JSON Schema 用灵活性换取了可靠性。"
|
|
},
|
|
"ja": {
|
|
"title": "全ツールに JSON Schema を定義",
|
|
"description": "各ツールは入力パラメータに対して厳密な JSON Schema を定義しています。例えば edit_file は old_string と new_string を正確な文字列として要求し、正規表現は使いません。これにより一連のバグを排除できます：API がスキーマに対して実行前にバリデーションを行うため、モデルは不正な入力を渡せません。モデルの意図も明確になります――特定の文字列で edit_file を呼び出す際、何を変更したいかについて解析の曖昧さがありません。",
|
|
"alternatives": "一部のエージェントシステムはモデルに自由形式のテキストを出力させ、正規表現やヒューリスティクスで解析します（例：markdown ブロックからコードを抽出）。これは脆弱です——モデルが出力を微妙に異なるフォーマットにするとパーサーが壊れます。JSON Schema は柔軟性を犠牲にして信頼性を得ています。"
|
|
}
|
|
}
|
|
]
|
|
}
|