[{"data":1,"prerenderedAt":205},["ShallowReactive",2],{"content-\u002Fcontents\u002Fagent-libos":3,"surroundPost-\u002Fcontents\u002Fagent-libos":196},{"id":4,"title":5,"body":6,"createdAt":180,"description":181,"draft":182,"extension":183,"meta":184,"navigation":185,"path":186,"seo":187,"stem":188,"tags":189,"thumbnail":194,"updatedAt":180,"__hash__":195},"contents\u002Fcontents\u002Fagent-libos.md","Agent libOS: A Library-OS-Inspired Runtime for Long-Running, Capability-Controlled LLM Agents",{"type":7,"value":8,"toc":158},"minimark",[9,13,17,20,23,26,29,32,35,38,41,44,47,50,53,56,59,62,65,75,78,86,89,97,101,106,109,113,116,120,123,127,130,134,137,141,144,148,151,155],[10,11,12],"h2",{"id":12},"どんな論文か",[14,15,16],"p",{},"この論文は、LLM エージェントを単発の request-response ではなく、長時間動く software actor として扱う。エージェントは状態を持ち、サブタスクを fork し、人間承認を待ち、外部副作用を起こし、あとから再開・監査される必要がある。",[14,18,19],{},"そこで著者は、agent を AgentProcess として扱う library-OS-inspired runtime substrate を提案する。AgentProcess は process identity、parent-child lineage、lifecycle state、tool table、typed Object Memory、explicit capabilities、human queues、checkpoints、events、audit records を持つ。",[14,21,22],{},"中心の設計原則は、tools are libc-like wrappers; runtime primitives are the authority boundary というもの。つまり、tool wrapper 側に権限境界を置くのではなく、filesystem access、object access、sleep、human approval、JIT tool registration、external side effects などを runtime primitive の境界でチェックする。",[14,24,25],{},"これは planner accuracy を上げる論文ではない。長時間エージェントを schedule、authorize、resume、audit するための基盤をどう置くか、という harness \u002F runtime 設計の論文として読むと価値が高い。",[14,27,28],{},"Agent libOS は、LLM agent を conventional OS の中で動く library runtime 上の実行主体として扱う。kernel-mode isolation や POSIX-compatible OS を作るのではなく、agent 用の lifecycle、memory、tool、capability、audit の管理面を runtime substrate としてまとめる。",[14,30,31],{},"論文の焦点は、長時間動く agent が外部世界へ副作用を持つとき、どこを信頼境界にするべきかという点にある。著者は tool dispatch ではなく runtime primitive を境界にするべきだと主張する。",[10,33,34],{"id":34},"課題と貢献",[14,36,37],{},"主要な貢献は、AgentProcess、AgentImage、typed Object Memory、explicit capabilities、human queues、checkpoints、events、audit records を含む runtime model の提示。",[14,39,40],{},"特に、tools を libc 的な薄い wrapper とみなし、実際の authority は runtime primitives 側に置く設計が読みどころ。これにより、filesystem\u002Fobject access、sleep、human approval、tool registration、external side effects を一貫した policy で制御しやすくなる。",[10,42,43],{"id":43},"手法のしくみ",[14,45,46],{},"Agent libOS では、agent は process identity と lifecycle state を持つ。parent-child lineage によって fork された subtasks を辿れるようにし、tool table は AgentImage から導かれる。",[14,48,49],{},"Object Memory は namespace-local で typed に扱われ、filesystem と object access は primitive 境界で capability check を受ける。human approval や one-shot permission grants も runtime に統合され、監査可能な record として残る。",[14,51,52],{},"JIT tool registration では Deno \u002F TypeScript tool を syscall broker 経由で扱い、tool を直接信頼境界にしない。外部副作用や shell 実行も runtime primitive に寄せて扱う。",[10,54,55],{"id":55},"検証結果",[14,57,58],{},"論文は Python prototype を実装し、async scheduling、namespace-local Object Memory、runtime-integrated human approval、one-shot permission grants、per-process working directories、filesystem\u002Fobject bridge tools、injectable Resource Provider Substrate を示す。",[14,60,61],{},"評価は safety-oriented な prototype evaluation と regression tests が中心で、執筆時点で 123 regression tests、deterministic demos、real-model smoke scripts があると報告されている。これは性能ベンチマークというより、runtime substrate と安全境界が一貫して動くかの確認に近い。",[10,63,64],{"id":64},"限界と読みどころ",[66,67,68,72],"ul",{},[69,70,71],"li",{},"Agent libOS は kernel OS ではなく、library runtime として設計されている。そのため hardware drivers、kernel-mode isolation、POSIX-compatible OS は目的外。",[69,73,74],{},"また、幅広い実運用比較や planner accuracy の改善を示す論文ではない。読む時は、agent の性能向上ではなく、長時間 agent の権限境界、再開、監査の設計語彙を得る論文として位置づけるのがよい。",[10,76,77],{"id":77},"読みながら見る図表や節",[66,79,80,83],{},[69,81,82],{},"読む時は、agent を process として扱う抽象と、tool wrapper ではなく runtime primitive に権限境界を置く抽象を中心に見る。",[69,84,85],{},"既存の agent harness、Codex skills、human approval、wiki memory、article-page-publisher のような長時間 workflow を、この AgentProcess \u002F capability \u002F checkpoint \u002F audit の語彙で読み替えると実務への引き出しが作りやすい。",[10,87,88],{"id":88},"次に読むなら",[66,90,91,94],{},[69,92,93],{},"次に読むなら、Agent libOS の design と threat model を精読し、Codex \u002F Claude Code \u002F personal assistant の harness に置き換えるとどの primitive が必要かを整理するとよい。",[69,95,96],{},"関連して読むなら、Code as Agent Harness、Harness-1、How to Interpret Agent Behavior、Counterfactual Trace Auditing など、agent runtime と evaluation を扱う論文とつなげると見通しがよくなる。",[10,98,100],{"id":99},"読後qa","読後Q&A",[102,103,105],"h3",{"id":104},"この論文の中心問いは","この論文の中心問いは？",[14,107,108],{},"長時間動き、副作用を持つ LLM agent を、安全に schedule、authorize、resume、audit する runtime substrate はどう設計できるか。",[102,110,112],{"id":111},"何が新しい","何が新しい？",[14,114,115],{},"agent を AgentProcess として扱い、tool dispatch ではなく runtime primitive を authority boundary にする設計を、Object Memory、capability、checkpoint、human approval、audit と一緒にまとめている点。",[102,117,119],{"id":118},"これは-os-を作る論文","これは OS を作る論文？",[14,121,122],{},"kernel OS ではなく、conventional host OS 上で動く library runtime の提案。POSIX 互換 OS や hardware driver を作る話ではない。",[102,124,126],{"id":125},"tools-are-libc-like-wrappers-とは","tools are libc-like wrappers とは？",[14,128,129],{},"tool は便利な wrapper であり、権限判断そのものは tool 側ではなく runtime primitive 側で行う、という設計原則。",[102,131,133],{"id":132},"実装では何を示している","実装では何を示している？",[14,135,136],{},"Python prototype で async scheduling、Object Memory、human approval、one-shot permission grants、working directories、Deno \u002F TypeScript JIT tools、syscall broker、regression tests などを示している。",[102,138,140],{"id":139},"どんな限界がある","どんな限界がある？",[14,142,143],{},"性能向上や広範な実運用比較が主眼ではない。評価は安全志向の prototype と regression tests が中心で、runtime 設計の提案として読むのがよい。",[102,145,147],{"id":146},"実務では何に効く","実務では何に効く？",[14,149,150],{},"agent skill、human approval、checkpoint \u002F resume、audit log、外部副作用の権限管理を、個別 tool の責任ではなく runtime \u002F harness の責任として整理できる。",[102,152,154],{"id":153},"関連して読むなら","関連して読むなら？",[14,156,157],{},"Code as Agent Harness、Harness-1、How to Interpret Agent Behavior、Counterfactual Trace Auditing など、agent harness と評価を扱う論文と相性がよい。",{"title":159,"searchDepth":160,"depth":160,"links":161},"",2,[162,163,164,165,166,167,168,169],{"id":12,"depth":160,"text":12},{"id":34,"depth":160,"text":34},{"id":43,"depth":160,"text":43},{"id":55,"depth":160,"text":55},{"id":64,"depth":160,"text":64},{"id":77,"depth":160,"text":77},{"id":88,"depth":160,"text":88},{"id":99,"depth":160,"text":100,"children":170},[171,173,174,175,176,177,178,179],{"id":104,"depth":172,"text":105},3,{"id":111,"depth":172,"text":112},{"id":118,"depth":172,"text":119},{"id":125,"depth":172,"text":126},{"id":132,"depth":172,"text":133},{"id":139,"depth":172,"text":140},{"id":146,"depth":172,"text":147},{"id":153,"depth":172,"text":154},"2026-06-03","長時間動く LLM エージェントを、状態・権限・再開・監査を持つ実行主体として扱う runtime substrate の論文。tool dispatch ではなく runtime primitive を権限境界に置く見方が、agent harness 設計に効く。",false,"md",{},true,"\u002Fcontents\u002Fagent-libos",{"title":5,"description":181},"contents\u002Fagent-libos",[190,191,192,193],"論文まとめ","Agent Runtime","Capability Control","Audit・Resume","\u002Farticle-pages\u002Fdocs\u002Fassets\u002Fgraphic-recordings\u002Fagent-libos.png","vD9AUZJPh3FF_qno1WMSx80F_VXEtpqD4FWDmMmafBk",[197,201],{"title":198,"path":199,"stem":200,"children":-1},"Agent Hooks Reading Guide","\u002Fcontents\u002Fagent-hooks-deterministic-control","contents\u002Fagent-hooks-deterministic-control",{"title":202,"path":203,"stem":204,"children":-1},"Agent Memory: Characterization and System Implications of Stateful Long-Horizon Workloads","\u002Fcontents\u002Fagent-memory-characterization","contents\u002Fagent-memory-characterization",1782055099202]