[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"article-faitheyes-tool-faithful-vision-agents-zh":3,"article-related-faitheyes-tool-faithful-vision-agents-zh":29,"series-ai-agent-a0e300e6-7ef0-48b3-b855-24c522751e57":72},{"id":4,"slug":5,"title":6,"content":7,"summary":8,"source":9,"source_url":10,"author":11,"image_url":12,"cover_image":12,"category":13,"language":14,"translated_content":11,"related_article_id":15,"keywords":16,"key_takeaways":22,"views":26,"created_at":27,"published_at":28,"topic_cluster_id":11},"a0e300e6-7ef0-48b3-b855-24c522751e57","faitheyes-tool-faithful-vision-agents-zh","FaithEyes 把工具服從訓練出來","\u003Cp data-speakable=\"summary\">以前是模型看起來很會用工具，現在是先把工具忠實度訓練進去，再讓它在視覺任務裡少亂猜。\u003C\u002Fp>\u003Cp>我這陣子一直在弄 \u003Ca href=\"\u002Ftag\u002Fagent\">agent\u003C\u002Fa> workflow，最煩的不是模型不會答，是它太愛自作主張。明明已經接了工具，結果它還是用嘴巴硬掰；明明該查圖、該算數、該驗證，它偏偏先講一個聽起來很順的答案。你一開始以為是推理壞掉，後來才發現根本是紀律壞掉。這種 bug 最討厭，因為它不會當場爆炸，只會\u003Ca href=\"\u002Fnews\u002Fwall-street-tokenization-slowly-not-celebrate-pilot-zh\">慢慢\u003C\u002Fa>把你的 pipeline 弄髒。\u003C\u002Fp>\u003Cp>所以我看到這篇 Zhihu 整理 \u003Ca href=\"https:\u002F\u002Fzhuanlan.zhihu.com\u002Fp\u002F2067555237938861816\">论文分享 | 智能体 最新进展\u003C\u002Fa>，一路點到 \u003Ca href=\"https:\u002F\u002Fgithub.com\u002FMosi-AI\u002FFaithEyes\">FaithEyes GitHub\u003C\u002Fa>，我就停下來看了。它講得很直白：用兩段式 SFT + RL，配合改過的開源資料，可以把視覺感知、推理和工具忠實度一起往上推。這句話我很買單，因為我現在最缺的不是會講話的模型，是會照規矩做事的模型。\u003C\u002Fp>\u003Cp>FaithEyes 這個名字聽起來有點宗教味，但方法論其實很務實。它不是在賣神奇感，而是在處理一個老問題：工具不是裝上去就會用，得訓練成習慣。\u003C\u002Fp>\u003Ch2>把工具使用當成政策，不要當成 prompt 花招\u003C\u002Fh2>\u003Cblockquote>Training via a two-stage SFT + RL pipeline on adapted open-source data, FaithEyes attains competitive or superior accuracy across visual perception and reasoning benchmarks, while markedly improving tool faithfulness.\u003C\u002Fblockquote>\u003Cp>翻譯一下就是：它不是只靠一句「請在需要時使用工具」來賭模型自律，而是把工具行為做成可學、可罰、可調的政策。先用 SFT 教它基本動作，再用 RL 把真正想要的行為推上去。這個順序很重要，因為工具使用本來就不是語言問題，是行為問題。\u003C\u002Fp>\n\u003Cfigure class=\"my-6\">\u003Cimg src=\"https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1786258991923-8v4x.png\" alt=\"FaithEyes 把工具服從訓練出來\" class=\"rounded-xl w-full\" loading=\"lazy\" \u002F>\u003C\u002Ffigure>\n\u003Cp>我以前也偷懶過。加個 tool schema、塞幾句 system prompt、再補一句「請謹慎使用工具」，看起來很完整，實際上常常只是把失控延後。簡單題它還會乖，題目一複雜就開始亂猜。最可怕的是它會把猜測包裝成自信答案，讓你以為它有查過。沒有，它只是很會演。\u003C\u002Fp>\u003Cp>實操寫法很直接：你要把「何時叫工具、何時不要叫、叫完怎麼根據結果回答」都變成訓練目標。資料裡要有三種樣本：必須叫工具、明明不用叫工具、叫完之後要修正原本猜測。少了這三種，你就只是在訓練一個更會講漂亮話的模型。\u003C\u002Fp>\u003Cul>\u003Cli>把工具調用視為決策，不是語氣。\u003C\u002Fli>\u003Cli>在資料裡明確標出「應呼叫」與「不應呼叫」的情境。\u003C\u002Fli>\u003Cli>讓模型學會看完工具結果再回答，不要先下結論再硬拗。\u003C\u002Fli>\u003C\u002Ful>\u003Ch2>SFT 先教動作，RL 再修掉投機\u003C\u002Fh2>\u003Cp>FaithEyes 的兩段式設計我覺得很對味，因為每一段在處理不同爛攤子。SFT 是模仿，先讓模型知道標準流程長什麼樣子；RL 是偏好塑形，逼它在壓力下也照這個流程走。這件事對 agent 特別重要，因為你真正要的不是「看起來像會用工具」，而是「在不確定時真的去用工具」。\u003C\u002Fp>\u003Cp>工具忠實度其實有兩層。第一層是機械層：格式對不對、參數有沒有亂填、工具輸出有沒有被照抄錯。第二層是判斷層：該不該叫工具、叫了之後有沒有老實根據結果回答、能不能在證據不足時停下來。很多模型第一層還行，第二層一塌糊塗，因為它太習慣靠語感補洞。\u003C\u002Fp>\u003Cp>我自己在測影像任務時就遇過這種狀況。SFT 完之後，乾淨題目它會照流程走；但一遇到模糊圖、遮擋圖、資訊不完整的圖，它就開始偷懶，直接用先驗知識補答案。RL 的價值就在這裡：你不是在抽象地獎勵「聰明」，你是在具體地懲罰「跳過工具還硬答」這種投機行為。\u003C\u002Fp>\u003Cul>\u003Cli>先用 SFT 教固定 trace：觀察、決策、呼叫、讀取、回答。\u003C\u002Fli>\u003Cli>再用 RL 獎勵 grounded answer、正確 tool choice、以及不亂編工具結果。\u003C\u002Fli>\u003Cli>reward 別搞太花，太花模型就學會鑽洞。\u003C\u002Fli>\u003C\u002Ful>\u003Cp>如果你的 reward 只看最後答案準不準，模型很可能偷偷省略工具步驟。如果你的 reward 連忠實度一起看，才有機會把行為拉回來。這就是 FaithEyes 讓我覺得實用的地方：它不是在修辭上講 agent，而是在訓練上管 agent。\u003C\u002Fp>\u003Ch2>開源資料可以用，但要先洗成行為資料\u003C\u002Fh2>\u003Cp>原文提到它是用 adapted open-source data。這個 adapted 我看得很重，因為這三個字通常就是整個方案的命門。開源資料本身不會自動變成 agent 訓練資料。原始資料常常格式混亂、任務風格不一、答案品質參差不齊，你如果直接倒進去，模型學到的通常不是能力，是雜訊。\u003C\u002Fp>\n\u003Cfigure class=\"my-6\">\u003Cimg src=\"https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1786258992520-16ah.png\" alt=\"FaithEyes 把工具服從訓練出來\" class=\"rounded-xl w-full\" loading=\"lazy\" \u002F>\u003C\u002Ffigure>\n\u003Cp>我理解這裡的做法，應該是把資料整理成符合目標行為的樣子。像是把平面的 QA 改成工具調用軌跡，把多模態樣本統一成同一種 trace，把不可靠的答案清掉，或把原本缺少步驟的樣本補成可學的決策序列。重點不是資料來源多漂亮，重點是資料能不能教出你要的政策。\u003C\u002Fp>\u003Cp>我看過不少團隊把 data prep 當清潔工活，這真的很浪費。對 agent 來說，資料整理本身就是模型設計。你沒有把行為順序寫進樣本，模型就只能自己猜；你把順序寫得亂七八糟，模型就會很有效率地學會亂七八糟。這種效率很可怕，因為它看起來像\u003Ca href=\"\u002Fnews\u002Fclaude-4-5-ai-progress-still-accelerating-zh\">進步\u003C\u002Fa>。\u003C\u002Fp>\u003Cul>\u003Cli>每筆樣本統一成固定 trace 格式。\u003C\u002Fli>\u003Cli>刪掉沒有觀察依據、卻硬給答案的樣本。\u003C\u002Fli>\u003Cli>把感知、推理、工具使用三類資料分開配比，別讓其中一類壓死其他類。\u003C\u002Fli>\u003C\u002Ful>\u003Cp>如果你本來就有自己的工具集，資料轉換規則一定要寫清楚。工具名稱、參數欄位、輸出格式，最好都固定。資料愈乾淨，後面 RL 才不會變成在救火。\u003C\u002Fp>\u003Ch2>工具忠實度才是 agent 真正的 KPI\u003C\u002Fh2>\u003Cp>我很喜歡原文把 “tool faithfulness” 拉出來講，這才是該被盯著的指標。很多 demo 看起來很聰明，因為它會講一堆話；但真正上線之後，最要命的往往不是答錯，而是它答錯得很像真的。工具忠實度就是在防這件事。\u003C\u002Fp>\u003Cp>什麼叫忠實？就是模型的最終回答要跟工具結果對得上。工具沒回那個數字，它不能自己補一個。工具明明已經給了證據，它不能裝作沒看到。工具告訴它 A，它不能最後\u003Ca href=\"\u002Fnews\u002Fasset-tokenization-turns-ownership-into-software-zh\">寫成\u003C\u002Fa> B 再用一堆漂亮句子包裝。這些都不是小錯，這些是會把產品搞爛的錯。\u003C\u002Fp>\u003Cp>我以前就被這種模型坑過。影像裡明明只有 3 個物件，它回我 4 個，還講得頭頭是道。你要是只看文字流暢度，會覺得它很會講；你要是看證據鏈，就會發現它根本沒在尊重事實。FaithEyes 值得看的地方，就是它把這件事當訓練目標，而不是事後審計。\u003C\u002Fp>\u003Cul>\u003Cli>把 tool call、tool output、final answer 分開記錄。\u003C\u002Fli>\u003Cli>單獨評分 final answer 是否被 tool output 支撐。\u003C\u002Fli>\u003Cli>加入拒絕猜測的負樣本，讓模型學會停手。\u003C\u002Fli>\u003C\u002Ful>\u003Cp>如果你做的是視覺助理，這點更重要。圖片最會騙人，因為人類自己也常常看錯。模型如果在不確定時願意說不知道，通常比硬猜一個看似合理的答案更有價值。\u003C\u002Fp>\u003Ch2>視覺感知和推理要分開施壓\u003C\u002Fh2>\u003Cp>原文還提到它在 visual perception 和 reasoning \u003Ca href=\"\u002Ftag\u002Fbenchmark\">benchmark\u003C\u002Fa> 上都有不錯表現。這句話我會解讀成：這套訓練不是只在某一種題型上刷分，而是有在照顧不同失敗模式。這很關鍵，因為感知錯和推理錯，根本不是同一種問題。\u003C\u002Fp>\u003Cp>感知錯通常是細節漏掉、定位不準、讀圖不乾淨；推理錯通常是步驟串錯、證據拿錯、太相信腦內猜測。你只補其中一邊，另一邊還是會炸。很多 agent stack 的毛病就在這裡，它們把所有東西都叫 reasoning，然後期待一個模型全包。結果就是看起來什麼都會，實際上什麼都不穩。\u003C\u002Fp>\u003Cp>實操上，我會把評估拆成幾個桶：感知、推理、工具選擇、工具忠實度、最後答案正確率。不要用一個總分把全部蓋掉。總分漂亮不代表系統可用，尤其是當某一桶已經爛到不行的時候。你如果沒拆開看，通常就是在自我安慰。\u003C\u002Fp>\u003Cul>\u003Cli>評估桶分開算，別只看 aggregate。\u003C\u002Fli>\u003Cli>保留模糊圖、遮擋圖、干擾圖，測模型會不會偷猜。\u003C\u002Fli>\u003Cli>把「需要再查一次」也當成可接受行為之一。\u003C\u002Fli>\u003C\u002Ful>\u003Cp>我很少講這麼直，但 agent 真的不能只靠單一分數活著。你要的是穩定，不是一次性的漂亮成績。\u003C\u002Fp>\u003Ch2>這套方法比一味追大模型更有用\u003C\u002Fh2>\u003Cp>我不是反對模型變大，變大通常是好事。但在 agent 場景裡，大不等於可靠。FaithEyes 讓我覺得實用，是因為它給了一條更可操作的路：先把行為訓練對，再談規模。對很多團隊來說，這比一直追 checkpoint 更實際，因為你真的能控制資料、控制 reward、控制行為定義。\u003C\u002Fp>\u003Cp>而且產品角度也很現實。你如果有一個稍微沒那麼花俏、但很忠實的模型，通常比一個什麼都敢答的模型好救很多。你少寫很多補丁，少做很多後處理，少跟使用者解釋「它差一點就對了」。這些時間省下來，才是真的。\u003C\u002Fp>\u003Cp>我自己的結論很簡單：如果你已經有夠用的 base model，下一輪迭代先別急著追更大。先把資料、訓練訊號、工具政策做紮實。很多 agent 的瓶頸不是智商，是它到底有沒有照證據做事。\u003C\u002Fp>\u003Cp>FaithEyes 給我的啟發就是這樣：模型不只要會答，還要知道自己該從哪裡答。\u003C\u002Fp>\u003Ch2>可抄的模板\u003C\u002Fh2>\u003Cpre>\u003Ccode># FaithEyes-style tool-faithful vision agent template\n\n## 目標\n訓練一個視覺代理，做到：\n- 證據不足時會叫工具\n- 證據足夠時不亂叫工具\n- 最終答案只根據觀察與工具輸出，不自己編\n\n## Stage 1: SFT\n\n### 統一資料格式\n每筆樣本固定包含：\n1. observation（圖像\u002F文字\u002F上下文）\n2. instruction（使用者任務）\n3. tool_policy（call_tool \u002F no_tool）\n4. tool_call（若需要）\n5. tool_output（工具回傳）\n6. final_answer（最後答案）\n\n### 範例 schema\n{\n  \"observation\": \"\u003Cimage\u002Ftext\u002Fcontext>\",\n  \"instruction\": \"\u003Cuser task>\",\n  \"tool_policy\": \"call_tool | no_tool\",\n  \"tool_call\": {\n    \"name\": \"\u003Ctool_name>\",\n    \"arguments\": {\n      \"...\": \"...\"\n    }\n  },\n  \"tool_output\": \"\u003Creturned evidence>\",\n  \"final_answer\": \"\u003Cgrounded response>\"\n}\n\n### SFT 資料原則\n- 加入必須用工具的正樣本\n- 加入不需要工具的反例\n- 加入「先猜錯、再根據工具修正」的樣本\n- 全部樣本統一成同一種 trace\n- 刪掉沒有證據卻硬答的資料\n\n## Stage 2: RL\n\n### reward components\n- task_accuracy：答案是否正確\n- tool_faithfulness：最後答案是否被工具輸出支撐\n- tool_choice：是否正確決定要不要叫工具\n- format_validity：工具呼叫格式是否正確\n\n### reward sketch\nreward =\n  1.0 * task_accuracy +\n  1.0 * tool_faithfulness +\n  0.5 * tool_choice +\n  0.2 * format_validity\n\n### penalties\n- hallucinated tool output\n- unsupported numerical claims\n- 該查卻不查\n- 不該查卻亂查\n- 工具結果和最終回答不一致\n\n## Evaluation buckets\n分開追蹤：\n- visual perception\n- visual reasoning\n- tool selection accuracy\n- tool faithfulness\n- final answer accuracy\n\n## Inference prompt\n你是一個會用工具的視覺代理。\n\n規則：\n1. 如果觀察已足夠，直接回答。\n2. 如果證據不足，呼叫適當工具。\n3. 不要編造工具結果。\n4. 最終回答只能根據觀察與工具輸出。\n\nUser task:\n{{instruction}}\n\nObservation:\n{{observation}}\n\n輸出：\n- decision\n- tool call（若需要）\n- grounded final answer\n\n## 上線前檢查\n- [ ] 我有工具使用與不使用工具的樣本嗎？\n- [ ] 我有把忠實度獨立評分嗎？\n- [ ] 每個答案都能追到觀察或工具輸出嗎？\n- [ ] 我有訓練模型拒絕亂猜嗎？\n- [ ] 我有把感知與推理分開評估嗎？\n\u003C\u002Fcode>\u003C\u002Fpre>\u003Cp>如果是我自己要開工，我會直接拿這份骨架去改：換成我的工具、我的任務標籤、我的 reward 權重。這才是重點。很多人只複製架構，沒複製行為定義，最後訓練出來的東西看起來像 agent，實際上只是更會裝懂。\u003C\u002Fp>\u003Cp>來源我點的是這篇 \u003Ca href=\"https:\u002F\u002Fzhuanlan.zhihu.com\u002Fp\u002F2067555237938861816\">Zhihu 整理文\u003C\u002Fa>，以及 \u003Ca href=\"https:\u002F\u002Fgithub.com\u002FMosi-AI\u002FFaithEyes\">FaithEyes GitHub repo\u003C\u002Fa>。我這篇是根據公開整理和 repo 入口做的方法論拆解，模板是我自己整理後改寫的，不是原文逐字照搬。\u003C\u002Fp>\u003Cp>如果你要追原始脈絡，也可以看 \u003Ca href=\"https:\u002F\u002Fgithub.com\u002FMosi-AI\u002FFaithEyes\">GitHub\u003C\u002Fa>、\u003Ca href=\"https:\u002F\u002Fzhuanlan.zhihu.com\u002Fp\u002F2067555237938861816\">Zhihu\u003C\u002Fa>，再對照相關作者與專案頁面去補細節。\u003C\u002Fp>","我拆 FaithEyes 的兩段式 SFT+RL 做法，順手給你一份可直接改的工具忠實視覺代理模板。","zhuanlan.zhihu.com","https:\u002F\u002Fzhuanlan.zhihu.com\u002Fp\u002F2067555237938861816",null,"https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1786258991923-8v4x.png","ai-agent","zh","b77650c4-7664-4af1-8ff1-2e1b792cdd58",[17,18,19,20,21],"SFT","RL","tool faithfulness","vision agents","agent training",[23,24,25],"工具使用要當成可訓練的政策，不要只靠 prompt 祈禱。","SFT 負責教流程，RL 負責修掉投機和亂猜。","資料整理本身就是模型設計，忠實度要獨立評估。",1,"2026-08-09T07:02:49.49712+00:00","2026-08-09T07:02:49.481+00:00",{"tags":30,"relatedLang":31,"relatedPosts":35},[],{"id":15,"slug":32,"title":33,"language":34},"faitheyes-tool-faithful-vision-agents-en","FaithEyes lets you train tool-faithful vision agents","en",[36,42,48,54,60,66],{"id":37,"slug":38,"title":39,"cover_image":40,"image_url":40,"created_at":41,"category":13},"33768f76-82d4-4f81-9d82-cee7b22af7c5","qwen-3-8-max-cli-integration-protocol-migration-zh","Qwen 3.8 Max CLI 接入与协议迁移","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1786255373107-rh9m.png","2026-08-09T06:02:30.328787+00:00",{"id":43,"slug":44,"title":45,"cover_image":46,"image_url":46,"created_at":47,"category":13},"10d812f4-bf80-40c4-9572-3f2346b1234d","fine-tune-small-llm-legal-labeling-zh","法律標註微調小型 LLM 產出","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1786150968538-nycr.png","2026-08-08T01:02:26.754363+00:00",{"id":49,"slug":50,"title":51,"cover_image":52,"image_url":52,"created_at":53,"category":13},"f538fedf-8816-4bfd-8c25-ef97be9f9d5d","sala-duance-ai-shangxiawen-kuozhan-zhinan-zh","SALA端侧AI上下文扩展操作指南","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1785765793001-wixs.png","2026-08-03T14:02:44.433703+00:00",{"id":55,"slug":56,"title":57,"cover_image":58,"image_url":58,"created_at":59,"category":13},"ac6e41ac-c8f1-4969-ab97-8662324881db","anthropic-breach-proves-ai-agents-need-hard-security-limits-zh","Anthropic 外洩證明 AI agents 必須先有硬性安全邊界","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1785742392018-5clf.png","2026-08-03T07:32:41.851393+00:00",{"id":61,"slug":62,"title":63,"cover_image":64,"image_url":64,"created_at":65,"category":13},"fa4ebd4b-b8e5-46bf-bd94-6f6e9008ab56","genai-mil-war-prompt-report-template-zh","把恐怖提示詞改成週報","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1785655978571-fadx.png","2026-08-02T07:32:38.01822+00:00",{"id":67,"slug":68,"title":69,"cover_image":70,"image_url":70,"created_at":71,"category":13},"435cd05e-f667-44ce-b362-598cab19269f","epam-openai-deal-turns-pilots-into-production-zh","EPAM 讓 AI 從試點變上線","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1785628985644-6uk4.png","2026-08-02T00:02:39.955798+00:00",[73,78,83,88,93,98,103,108,113,118],{"id":74,"slug":75,"title":76,"created_at":77},"4ae1e197-1d3d-4233-8733-eafe9cb6438b","claude-now-uses-your-pc-to-finish-tasks-zh","Claude 開始幫你操作電腦","2026-03-26T07:20:48.457387+00:00",{"id":79,"slug":80,"title":81,"created_at":82},"5bede67f-e21c-413d-9ab8-54a3c3d26227","googles-2026-ai-agent-report-decoded-zh","Google 2026 AI Agent 報告解讀","2026-03-26T11:15:22.651956+00:00",{"id":84,"slug":85,"title":86,"created_at":87},"2987d097-563f-46c7-b76f-b558d8ef7c2b","kimi-k25-review-stronger-still-not-legend-zh","Kimi K2.5 評測：更強，但還不是神作","2026-03-27T07:15:55.277513+00:00",{"id":89,"slug":90,"title":91,"created_at":92},"95c9053b-e3f4-4cb5-aace-5c54f4c9e044","claude-code-controls-mac-desktop-zh","Claude Code 也能操控 Mac 了","2026-03-28T03:01:58.58121+00:00",{"id":94,"slug":95,"title":96,"created_at":97},"dc58e153-e3a8-4c06-9b96-1aa64eabbf5f","cloudflare-100x-faster-ai-agent-sandbox-zh","Cloudflare 的 AI 沙箱跑超快","2026-03-28T03:09:44.142236+00:00",{"id":99,"slug":100,"title":101,"created_at":102},"1c8afc56-253f-47a2-979f-1065ff072f2a","openai-backs-isara-agent-swarm-bet-zh","OpenAI 挺 Isara 的 agent swarm …","2026-03-28T03:15:27.513155+00:00",{"id":104,"slug":105,"title":106,"created_at":107},"7379b422-576e-45df-ad5a-d57a0d9dd467","openai-plan-automated-ai-researcher-zh","OpenAI 想做自動化 AI 研究員","2026-03-28T03:17:42.090548+00:00",{"id":109,"slug":110,"title":111,"created_at":112},"48c9889e-86df-450b-a356-e4a4b7c83c5b","harness-engineering-ai-agent-reliability-2026-zh","駕馭工程：從「馬具」到「作業系統」，AI Agent 可靠性的終極密碼","2026-03-31T06:42:53.556721+00:00",{"id":114,"slug":115,"title":116,"created_at":117},"96d8e8c8-1edd-475d-9145-b1e7a1b02b65","mcp-explained-from-prompts-to-production-zh","MCP 怎麼把提示詞變工作流","2026-04-01T09:24:39.321274+00:00",{"id":119,"slug":120,"title":121,"created_at":122},"f2ca7720-b471-4ce5-9336-2a9ac2a876fd","amazon-bedrock-agents-multi-agent-workflows-zh","Amazon Bedrock Agents 進入多代理工作流","2026-04-01T09:30:29.945429+00:00"]