Agent-Computer-Interface

Properties2
tags狀態/草稿
aliasesACI, Agent Computer Interface

閱讀時間約 5 分鐘

Agent-Computer-Interface

一句話定義

Anthropic 提出的設計概念：Agent 與工具 / 環境之間的互動界面。需要透過完善的工具文件、清楚的參數命名、廣泛測試與「防呆（poka-yoke）」原則來打造，以最大化 agent 的可靠性。

核心要點

工具格式建議

  • 為「執行前的 reasoning」分配 token 空間
  • 格式接近自然出現在網路文本的形式
  • 消除格式 overhead（行號、字串轉義等）

工具設計指引

  • 包含使用範例、邊界案例、格式要求、與其他工具的界線
  • 參數名與描述清楚
  • 用多樣輸入廣泛測試
  • poka-yoke（防呆）原則——讓錯誤難以發生（例：要求絕對路徑而非相對路徑，避免 agent 誤解工作目錄）

協議化介面

Model-Context-Protocol 與 Agent2Agent 都可視為 ACI 的協議化延伸：前者規範 agent 如何看見與使用工具 / 資料源，後者規範 agent 如何發現其他 agent、提交任務、追蹤狀態與取得 artifact。

工具設計實證（SWE-agent paper，2026-05-02-Harness-Engineering駕馭工程 引用）

早期 ACI 詞彙來自 SWE-agent（2024）：給模型不同工具會大幅影響能力，但人類好用的工具不一定適合 LLM。

工具設計結果
搜尋（無）用 ls / grep 找檔案baseline
搜尋（類人類分頁）一次給部分結果，可翻頁比 baseline 還差——agent 會把每頁都點完，把 context 灌爆
搜尋（帶摘要）直接給摘要 + 相關檔名最好——agent 自己決定要不要打開細看
edit（指定行範圍）給「修改第 X 到 Y 行」工具比 baseline 還容易出錯——只看片段不知全貌、容易多括號等語法錯
edit（行範圍）+ linting加上即時語法檢查工具回饋正向收益——edit 必須配 lint 才有用
  • 教訓 1：人類好用 ≠ LLM 好用——分頁搜尋是人類網頁瀏覽習慣，LLM 沒有「累了該停了」的直覺。
  • 教訓 2：單一工具沒設計好可能負收益，需要工具組合（edit + lint）才能 net 正向——對位 Harness-Engineering 「控制能力邊界（工具設定）」紀律。

Agent-First CLI 設計趨勢（Google 案例）

  • 過去 CLI 是給人用的（flag 為主、自然語言參數）；agent 用同樣 CLI 表現次於原生工具。
  • Google Workspace CLI 為 AI 重寫，明確標榜 agent first——agent 喜歡結構化（JSON in CLI） 勝過 flag；人類寫 JSON 容易錯（括號不配對），AI 不會錯。
  • 未來服務都會分裂出 agent CLI——服務一旦預期被 agent 使用，介面設計必須重做。

與其他概念的關係

  • 是 Agent 三大成功原則之一（簡潔、透明、ACI）。
  • 與 Prompt-Engineering 緊密相關：原文章把 ACI 稱為「prompt engineering your tools」——用 prompt engineering 的精神設計工具介面。
  • 對 Augmented-LLM 的工具層特別關鍵：augmented LLM 用得好不好，往往看 ACI 設計得好不好。
  • 與 Agent2Agent 相關：Agent Card、Task 狀態、Message parts 與 Artifact 都是 agent-to-agent 介面的可用性設計。
  • 父概念：Harness-Engineering —— ACI 是 Harness 三大手段中「控制能力邊界（工具設定）」的工具子層；harness 在工具設計上的紀律 = ACI 的核心議題。

相關來源

備註

反向連結