<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Autonomous Systems on YennJ12 Engineering Blog</title><link>https://yennj12.js.org/yennj12_blog_V4/tags/autonomous-systems/</link><description>Recent content in Autonomous Systems on YennJ12 Engineering Blog</description><generator>Hugo -- gohugo.io</generator><language>en-us</language><lastBuildDate>Mon, 22 Jun 2026 01:00:00 +0800</lastBuildDate><atom:link href="https://yennj12.js.org/yennj12_blog_V4/tags/autonomous-systems/feed.xml" rel="self" type="application/rss+xml"/><item><title>AI 工程從零開始｜Phase 15 Part 1：長時程自主系統 — 跨天任務的 Agent 工程</title><link>https://yennj12.js.org/yennj12_blog_V4/posts/ai-eng-from-scratch-phase15-part1-long-horizon-zh/</link><pubDate>Mon, 22 Jun 2026 00:30:00 +0800</pubDate><guid>https://yennj12.js.org/yennj12_blog_V4/posts/ai-eng-from-scratch-phase15-part1-long-horizon-zh/</guid><description>大多數人把 Agent 設計成「一問一答」的延伸版本——輸入一個任務，等待一個輸出。 長時程任務打破了這個假設：任務可能跨越數小時、數天、數十個 LLM 呼叫。 短時程 Agent 的容錯率是 5%，長時程 Agent 的錯誤會複利累積，五十步後完成率可能跌到 5%。 真正的長時程 Agent 工程，是在不確定性中建立可恢復、可審計、可協作的執行系統。
面試情境 你的團隊正在建構一個自動化程式碼審查 Agent，需要在 72 小時內分析一個大型 monorepo 的 3000 個 PR，並針對每個 PR 產出安全性報告、效能建議與合規性評估。這個 Agent 在執行到第 800 個 PR 時崩潰重啟，你如何設計系統確保任務能從斷點繼續、不重複分析已完成的 PR、且最終報告的品質不會因為長時間執行而漂移？
一、核心問題：為什麼長時程任務對 Agent 是質的挑戰 1.1 短時程 vs 長時程的根本差異 大多數 LLM Agent 的設計假設是「無狀態、單輪、短暫」：使用者提問，Agent 在一個 context window 內完成推理，回傳答案，會話結束。這個模型在 RAG 問答、程式碼補全、單步工具呼叫等場景運作良好。
長時程任務打破了所有這些假設：
時間跨度：任務可能需要 2 小時、2 天、甚至 2 週才能完成 狀態複雜度：中間狀態數量可達數千個節點，無法全部放入 context window 錯誤複利：每一步有 2% 的錯誤率，50 步後完成率僅剩 36%（0.98^50 ≈ 0.364） 外部世界變化：任務執行期間，外部環境可能發生變化（程式碼庫更新、API 回應格式改變） 人工干預需求：某些決策點需要人類確認，無法全程自動化 1.</description></item><item><title>AI 工程從零開始｜Phase 15 Part 2：自我改進與 2026 安全技術棧</title><link>https://yennj12.js.org/yennj12_blog_V4/posts/ai-eng-from-scratch-phase15-part2-self-improvement-safety-zh/</link><pubDate>Mon, 22 Jun 2026 01:00:00 +0800</pubDate><guid>https://yennj12.js.org/yennj12_blog_V4/posts/ai-eng-from-scratch-phase15-part2-self-improvement-safety-zh/</guid><description>大多數工程師把安全當成事後的 checklist。 真正的 AI 工程師在架構第一行就把安全嵌入設計核心。 自我改進讓模型更強大；安全技術棧讓這份強大不會反噬使用者。 兩者缺一，你只是在玩一把沒有安全裝置的槍。
面試情境 你的公司正在部署一個能夠自主執行程式碼、搜尋網路、並呼叫內部 API 的 AI Agent。產品 VP 問你：「如果這個 Agent 被攻擊者注入惡意指令，最壞的情況是什麼？你會怎麼在不犧牲能力的前提下設計防禦架構？」
一、核心問題：自我改進的工程機會與安全風險 1.1 為什麼自我改進讓工程師又期待又害怕 2025 年末到 2026 年，生產環境中的 AI Agent 已從「問答機器」進化為「能夠修改自身行為的系統」。Self-Refinement 讓模型在推論時迭代改寫輸出；Constitutional AI 讓模型以原則自我審查；RLVR（Reinforcement Learning from Verifiable Rewards）讓模型從可驗證的結果信號中自我強化。
這三項技術加在一起，意味著一件事：模型的行為邊界不再是靜態的。這對工程師是機會，也是惡夢。
機會在於：每次推論都是一次微小的「學習」，系統越用越精準。 惡夢在於：如果攻擊者能夠注入惡意目標函數，系統會自我強化朝錯誤方向走，而且速度比你想像的快。
1.2 2026 年三大安全威脅面 威脅類型 典型攻擊向量 最壞後果 2026 發生率 提示注入（Prompt Injection） 惡意使用者輸入覆蓋系統提示 資料外洩、未授權操作 生產事故中佔 34% 越獄（Jailbreak） 繞過安全訓練的對話技巧 有害內容生成 OWASP LLM Top 10 第一位 行動劫持（Action Hijacking） 透過 RAG 文件注入惡意工具呼叫 刪除資料、外部 API 濫用 2026 Q1 新興威脅 這篇文章的核心主張：自我改進機制與安全防禦必須共設計（co-designed），不能分開考慮。</description></item></channel></rss>