Mọi người đều hỏi "WTF là một loop?" Nhưng có một câu hỏi không ai hỏi: cái gì chạy loop đó?
Các cuộc thảo luận về AI đã hội tụ về loops như một nguyên thủy cốt lõi của các hệ thống agent. Matt Van Horn (@mvanhorn) đã truy vết nguồn gốc của agent loops từ ReAct đến tool-use, đến orchestration loops, đến loops giám sát loops. Addy Osmani (@addyosmani) đã phân tích các khối xây dựng bên trong loops: automations, worktrees, skills, connectors, sub-agents. Van Horn nhấn mạnh vào durability, lập luận rằng loops không thể sống sót sau khi khởi động lại thì không phải là loops. Điểm chính của Osmani là orchestration: thiết kế hệ thống nhắc nhở agent thay vì bạn.
Tôi muốn đưa quan điểm của họ đi xa hơn. Durability không chỉ là một thuộc tính của loop. Nó là toàn bộ lớp thực thi bên dưới. Sự thật quan trọng là orchestration bền vững là nền tảng để xây dựng kiến trúc agent loop của bạn. Hãy phân tích kiến trúc đó.
Nơi loops bị hỏng
Các mẫu /loop và /goal xử lý công việc single-agent, single-session tốt. Một agent lặp cho đến khi hoàn thành nhiệm vụ. Điều đó bao phủ nhiều tình huống. Nhưng giai đoạn tiếp theo (Giai đoạn 5 trong khung của Van Horn) là nơi nó sụp đổ:
- Loops giám sát các loops khác
- Loops chạy theo lịch trình, không chỉ do con người kích hoạt
- Loops sống sót sau khi khởi động lại process, triển khai và sự cố
- Loops tạo ra sub-agents và chờ kết quả (đôi khi hàng giờ sau)
- Loops cần được quan sát sau khi sự việc xảy ra
Đó không phải là vấn đề về prompting. Đó là vấn đề về hạ tầng.
Van Horn trích dẫn @runes_leo: "Điều tốn kém nhất trong lập trình AI không còn là viết code, mà là quản lý agent loop." Một vòng lặp while True trong terminal không cung cấp cho bạn bất kỳ điều nào ở trên. Một process chạy dài trên VM hoặc sandbox cũng vậy.
Hãy nghĩ về điều gì xảy ra khi bạn chạy một agent loop trên server. Process sẽ chết hoặc khởi động lại. Một lần triển khai, OOM, thu hồi spot instance. Loop khởi động lại. Nhưng nó đang làm gì? Nó đang ở bước nào? Nó đã gửi tin nhắn Slack đó chưa? Nó đã gọi sub-agent chưa?
Bạn không biết. Nó bắt đầu lại. Lấy lại dữ liệu nó đã có. Gọi lại LLM cho các quyết định nó đã đưa ra. Gửi thông báo trùng lặp. Tạo ra sub-agent trùng lặp. Bạn thức dậy với ba tin nhắn Slack giống hệt nhau và một đội ngũ bối rối.
Giải pháp không phải là "xử lý lỗi tốt hơn" — mà là một mô hình thực thi nơi mỗi bước được checkpoint, mỗi quyết định được lưu trữ và phục hồi có nghĩa là tiếp tục từ bước thành công cuối cùng.
Kiến trúc agent loop trong ba lớp
Ba lớp. Mỗi lớp ánh xạ đến một nguyên thủy cụ thể.
Lớp 1: Loop
Một loop là một cron cộng với một bộ ra quyết định. Nó chạy theo lịch trình (hoặc một trigger), đánh giá trạng thái và quyết định làm gì tiếp theo.
Đây là định nghĩa của Van Horn được cụ thể hóa: những gì cron chưa bao giờ có là quyết định ở giữa. Agent quyết định, không phải bạn. Cron là nhịp tim. LLM là bộ ra quyết định. Steps là quá trình thực thi bền vững checkpoint tiến trình.
1export const infraHealthCheck = inngest.createFunction(2 { id: "infra-health-check" },3 { cron: "*/30 * * * *" }, // Mỗi 30 phút4 async ({ step }) => {5 const metrics = await step.run("fetch-service-metrics", async () => {6 return await fetchServiceMetrics(); // tỷ lệ lỗi, độ trễ, bộ nhớ, CPU7 });89 const assessment = await step.run("assess-health", async () => {10 return await callLLM({11 prompt: `Với các số liệu dịch vụ này, hãy phân loại tình trạng hệ thống tổng thể12 là "bình thường", "suy giảm" hoặc "nghiêm trọng". Giải thích lý do.13 Số liệu: ${JSON.stringify(metrics)}`,14 });15 });1617 if (assessment.status === "degraded" || assessment.status === "critical") {18 await step.invoke("triage-incident", {19 function: incidentTriage,20 data: { metrics, assessment, services: assessment.affectedServices },21 });22 }23 }24);
Mỗi thứ Hai lúc 9 giờ sáng, loop kích hoạt. Nó lấy dữ liệu, hỏi LLM liệu có cần báo cáo hay không và gọi một skill nếu có. Nếu process khởi động lại giữa các bước, các bước đã hoàn thành sẽ không thực thi lại. Đó là loop. Không phải LLM, mà là loop bao quanh LLM.
Lớp 2: Skill
Trong bối cảnh này, skill không phải là một prompt. Nó là một workflow bền vững. Nhiều bước, có thể retry, có thể kết hợp, có thể triển khai độc lập.
Van Horn: "Loop là hệ thống ống dẫn. Tài sản là skill mà nó gọi." Đây là phần có giá trị gia tăng. Mỗi skill mới mà hệ thống học được làm cho mọi loop trở nên mạnh mẽ hơn.
1export const incidentTriage = inngest.createFunction(2 { id: "incident-triage", retries: 3 },3 { event: "infra.incident.triage" },4 async ({ event, step }) => {5 const details = await step.run("fetch-detailed-metrics", async () => {6 return await fetchDetailedMetrics({ services: event.data.services });7 });89 const deploys = await step.run("fetch-deploy-history", async () => {10 return await fetchRecentDeploys({ since: hoursAgo(2) });11 });1213 const analysis = await step.run("correlate-incident", async () => {14 return await callLLM({15 prompt: `Tương quan các số liệu dịch vụ này với các bản triển khai gần đây.16 Xác định nguyên nhân gốc rễ có khả năng nhất và mức độ nghiêm trọng.17 Số liệu: ${JSON.stringify(details)}18 Triển khai gần đây: ${JSON.stringify(deploys)}`,19 });20 });2122 await step.run("post-triage-summary", async () => {23 await slack.postMessage({24 channel: "#incidents",25 text: formatTriageSummary({26 analysis,27 affectedServices: event.data.services,28 recommendedActions: analysis.recommendations,29 }),30 });31 });3233 return analysis;34 }35);
Skill này tìm nạp, phân loại và định tuyến. Nó là một đơn vị công việc có khả năng chịu lỗi tích hợp. Skill có thể là một workflow AI với LLM ở giữa hoặc code xác định.
Lớp 3: Orchestrator
Orchestrator là engine chạy mọi thứ: lên lịch cron, thực thi các bước, quản lý retry, áp dụng giới hạn đồng thời, lưu trữ lịch sử chạy và triển khai nóng các function/workflow mới mà không làm gián đoạn các function đang chạy.
Đây là lớp không ai nói đến vì nó được cho là vô hình. Nhưng nó là nền tảng.
Hầu hết mọi người nghĩ về agent là "LLM + tools." Kiến trúc agent loop định nghĩa lại rằng agent là "loops + skills + orchestration." LLM + tools nằm bên trong loops. LLM và tools có thể được hoán đổi hoặc tinh chỉnh trong khi kiến trúc vẫn giữ nguyên. Orchestration cho phép kiến trúc hoạt động.
Điều gì xảy ra khi mọi thứ hỏng hóc
Con đường suôn sẻ thì dễ. Nhưng đây là phần mềm chạy trong production, mọi thứ có bao giờ thực sự diễn ra theo kế hoạch không?
Skill incident triage của bạn kích hoạt và API metrics bị timeout. Lần đọc phải vào đĩa và bộ nhớ đệm in-memory không có dữ liệu. Bước gọi API này bây giờ retry và gọi lại API. Dữ liệu bây giờ được lưu trong bộ nhớ đệm một phần và API hoàn thành. Skill tiếp tục với bước tiếp theo như thể không có chuyện gì xảy ra.
Đôi khi, nó có thể không đơn giản như vậy. Điều gì xảy ra nếu khóa API hết hạn hoặc nhà cung cấp hosting của bạn ngừng hoạt động trong 30 phút? Tất cả các lần retry của bạn đều cạn kiệt. Bây giờ thì sao? Bạn cũng phải xử lý các lỗi.
1export const incidentTriage = inngest.createFunction(2 {3 id: "incident-triage",4 retries: 3,5 onFailure: async ({ error, event, step }) => {6 // Hàm thất bại sau khi đã retry hết.7 // Chúng ta vẫn có dữ liệu sự kiện gốc. Không có gì bị mất.8 await step.run("notify-failure", async () => {9 await slack.postMessage({10 channel: "#agent-ops",11 text: `⚠️ Incident triage thất bại: ${error.message}. ` +12 `Sẽ retry trong chu kỳ kiểm tra sức khỏe tiếp theo. ` +13 `Các dịch vụ bị ảnh hưởng: ${event.data.services.join(", ")}`,14 });15 });16 },17 },18 { event: "infra.incident.triage" },19 async ({ event, step }) => {20 /* cùng logic với skill ở trên */21 }22);
Trình xử lý \onFailure\ kích hoạt sau khi tất cả các lần retry đã cạn kiệt. Nó đăng lên kênh ops để ai đó biết. Sự kiện được lưu giữ, không có gì bị mất. Lần chạy theo lịch trình tiếp theo sẽ tiếp tục từ nơi lần thất bại không thể tiếp tục.
Orchestration bền vững phải cung cấp cho bạn retry cấp bước cho các lỗi tạm thời và các hook xử lý lỗi cho các lỗi không thể phục hồi. Nếu không có điều này, mọi thứ sẽ hỏng hóc (như chúng vẫn thường xảy ra) và bạn sẽ phát hiện ra hàng giờ hoặc hàng ngày sau đó.
Các lỗi tạm thời cũng rất tốn kém. Nếu skill hoặc agent của bạn retry từ đầu, bạn sẽ gọi LLM nhiều lần và đốt token một cách không cần thiết. Cuộc gọi LLM có thể được checkpoint. Bây giờ nhân số này lên 10, hoặc 30, agent trong hệ thống của bạn. Điều đó rất tốn kém.
Checkpointing cấp bước không chỉ là một tính năng đảm bảo tính đúng đắn. Nó là một công cụ tiết kiệm tiền.
Agent tự xây dựng kỹ năng của riêng mình
Đây là nơi mọi thứ trở nên thú vị hơn. Hệ thống không tĩnh, nó được thiết kế để tiến hóa và tự mở rộng.
Agent không chỉ chạy bên trong loops — nó tạo ra các loops mới và đăng ký chúng với orchestration engine. Mỗi function được triển khai là một skill bền vững chạy độc lập, có thể kích hoạt từ một loop hoặc agent hoặc chạy theo lịch trình, với logic rety riêng. Các skill kết hợp với nhau.
Đó là một agent nhận biết được orchestration.
Đây là cách nó hoạt động. Một AI agent có quyền truy cập vào orchestration SDK như một tool. Nó có thể viết các function mới, đăng ký chúng với engine và chúng bắt đầu chạy ngay lập tức. Process agent tải nóng các function mới mà không cần khởi động lại hoặc làm gián đoạn các lần chạy đang diễn ra.
Hãy xem xét một ví dụ cụ thể:
1. Con người bày tỏ nhu cầu. Kỹ sư nói: "Dịch vụ của chúng tôi liên tục bị tăng độ trễ vào ban đêm và không ai để ý cho đến sáng." Đây là trigger. Agent không cần suy luận một mẫu mơ hồ từ dữ liệu xung quanh. Nó có hướng dẫn rõ ràng.
2. Agent viết một skill. Hai function nhiều bước: một loop kiểm tra sức khỏe chạy mỗi 30 phút, lấy tỷ lệ lỗi, độ trễ và mức sử dụng tài nguyên, với LLM phân loại tình trạng hệ thống là bình thường, suy giảm hoặc nghiêm trọng. Và một skill incident triage lấy số liệu chi tiết và lịch sử triển khai gần đây, tương quan nguyên nhân gốc rễ với LLM và đăng một bản tóm tắt phân loại lên Slack với các hành động được đề xuất. Xử lý lỗi: nếu API metrics bị down, hãy back off và retry. Nếu LLM bị lỗi, hãy fallback về phân loại mức độ nghiêm trọng dựa trên quy tắc.
3. Agent triển khai skill. Agent viết mã function được một process sidecar nhặt lên. Các function mới được đăng ký tự động. Chúng hoạt động ngay lập tức, không cần pipeline triển khai, không cần PR.
4. Skill chạy tự động. Mỗi 30 phút, engine kích hoạt kiểm tra sức khỏe. Nếu có vấn đề, nó gọi skill triage. Không có con người trong loop. Hoàn toàn bền vững.
5. Agent lặp lại dựa trên tín hiệu. Đây là phần mọi người lướt qua, vì vậy hãy để tôi nói cụ thể về "lặp lại" có nghĩa là gì. Agent không kỳ diệu nhận thấy các mẫu. Nó có một vòng lặp đánh giá riêng: một function kích hoạt cron chạy hàng tuần, đọc lịch sử chạy từ orchestrator và đánh giá hiệu suất:
1export const reviewSkillPerformance = inngest.createFunction(2 { id: "review-skill-performance" },3 { cron: "0 10 * * 5" }, // Mỗi thứ Sáu lúc 10 giờ sáng4 async ({ step }) => {5 const runs = await step.run("fetch-run-history", async () => {6 return await getInngestRuns({7 functionId: "incident-triage",8 since: daysAgo(7),9 });10 });1112 const analysis = await step.run("analyze-performance", async () => {13 const successRate = runs.filter(r => r.status === "completed").length / runs.length;14 const avgDuration = average(runs.map(r => r.duration));15 const incidents = await fetchIncidentOutcomes(); // Các sự cố có tương quan với outages thực tế không?1617 return await callLLM({18 prompt: `Đánh giá hiệu suất của skill này trong tuần qua.19 Tỷ lệ thành công: ${successRate}20 Thời lượng trung bình: ${avgDuration}ms21 Sự cố tương quan với outages thực tế: ${incidents.confirmed}/${incidents.total}22 Dương tính giả: ${incidents.falsePositives}23 Nhóm đã hành động theo cảnh báo: ${incidents.actedOn}/${incidents.total}2425 Chúng tôi có nên điều chỉnh ngưỡng hoặc phân loại? Những thay đổi cụ thể nào?`,26 });27 });2829 if (analysis.shouldModify) {30 await step.invoke("update-skill", {31 function: coreAgent,32 data: { prompt: `Cập nhật skill incident-triage dựa trên các thay đổi được đề xuất sau: ${analysis.proposedChanges}` },33 });34 }35 }36);
"Đánh giá" là một function. Nó đọc lịch sử chạy, kiểm tra xem các sự cố có tương quan với các outages thực tế không và cung cấp tín hiệu đó cho LLM. Nếu kiểm tra sức khỏe liên tục gắn cờ một dịch vụ là bị suy giảm nhưng nhóm bỏ qua vì ngưỡng quá nhạy, vòng lặp đánh giá sẽ bắt được điều đó và skill được cập nhật để điều chỉnh phân loại. Không phải ma thuật. Một cron job với LLM ở vị trí ra quyết định.
Còn về xác thực thì sao? Agent viết code chỉ tốt như các rào cản xung quanh nó. Mã có thể được kiểm tra kiểu. Agent có thể tự gọi function để kiểm tra nó vì nó có thể tương tác với chính orchestration engine. Mặc dù không hoàn toàn chống đạn, bạn đang cung cấp cho agent chính khả năng gỡ lỗi các skills nó viết một cách tự nhiên trong hệ thống nó hoạt động. Vòng lặp đánh giá bắt các vấn đề không được phát hiện trong lần gỡ lỗi ban đầu.
Đưa điều này xa hơn một bước, agent có thể sử dụng các hook onFailure để tự kích hoạt đánh giá một lỗi nhất định. Đó là một vòng lặp phản hồi liên tục cải thiện.
Còn về xung đột thì sao? Các kiểm soát luồng, cụ thể là kiểm soát đồng thời hoặc singleton xử lý trường hợp đơn giản (concurrency: \{ limit: 1, key: "[event.data.service" }]) có nghĩa là chỉ một incident triage chạy tại một thời điểm cho mỗi dịch vụ. Nhưng câu hỏi sâu hơn là: điều gì sẽ xảy ra nếu hai health check phát hiện vấn đề trong cùng một dịch vụ cùng lúc? Orchestrator xếp chúng vào hàng đợi. Lần triage thứ hai đợi cho đến khi lần đầu tiên hoàn thành. Không có cảnh báo trùng lặp, không có điều kiện race. Điều này không phải lý thuyết. Đó là nguyên thủy đồng thời giống như bạn sẽ sử dụng trong bất kỳ hàng đợi công việc nào.
Agent không chỉ thực thi các tác vụ. Nó đang xây dựng cơ sở hạ tầng cho chính nó. Mỗi skill bền vững tồn tại lâu hơn cuộc trò chuyện đã tạo ra nó. Giết process agent và khởi động lại nó. Các skill tiếp tục chạy. Hoán đổi mô hình cơ bản. Các skill tiếp tục chạy. Agent là phù du — đầu ra của nó là bền vững.
Tổng quan hệ thống kiến trúc Agent Loop
Góc nhìn của nhà phát triển
Điều này quan trọng bởi vì nếu nhà phát triển không thể thấy những gì agent đã triển khai, gỡ lỗi những gì bị hỏng và kiểm tra những gì đã chạy lúc 3 giờ sáng, thì toàn bộ kiến trúc là một rủi ro lớn.
Orchestration engine lưu trữ mọi lần chạy, mọi bước, mọi đầu vào, mọi đầu ra, mọi lần retry. Một skill mà agent đã triển khai vào thứ Ba tuần trước bị lỗi lúc 4 giờ sáng? Bạn có thể thấy chính xác bước nào bị lỗi, đầu vào là gì, lỗi nó đưa ra là gì và nó đã retry bao nhiêu lần trước khi từ bỏ. Dấu vết đầy đủ xuống cấp bước là đầu ra của chính orchestration engine.
Đây không phải là một bảng điều khiển được gắn vào sau khi sự việc xảy ra. Nó vốn có trong thực thi bền vững. Mỗi step.run() là một checkpoint. Mỗi checkpoint đều có thể quan sát được. Khi thứ viết mã không phải là con người, khả năng quan sát không phải là một thứ tốt để có — nó là lớp tin cậy.
Hàng ngày, quy trình làm việc của nhà phát triển trông như thế này: kiểm tra bảng điều khiển các lần chạy vào buổi sáng. Xem những skill nào đã chạy qua đêm, cái nào thành công, cái nào thất bại. Nếu một skill mà agent viết hoạt động sai, bạn có thể đọc trực tiếp mã, chỉnh sửa nó, xóa nó hoặc yêu cầu agent sửa nó. Agent đã tạo ra nó, nhưng bạn sở hữu nó. Agent và các skill của nó vẫn là một khu vườn mà bạn nên chăm sóc.
Tại sao durability là nền tảng
Van Horn: "Những thứ này phải sống sót sau một lần khởi động lại."
Đây là ý nghĩa của durability trong thực tế:
Yêu cầu
Ý nghĩa
Tại sao while loop cơ bản thất bại
Retry bước độc lập
Nếu bước 3 của 5 thất bại, hãy retry bước 3, không phải bước 1 và 2
Khởi động lại loop chạy lại mọi thứ từ đầu
Vòng đời sub-agent
Tạo một tác vụ con, chờ nó (có thể hàng giờ), hủy nếu parent bị hủy
Không có quản lý vòng đời cha-con tích hợp
Phân phối sự kiện đảm bảo
Nếu một sự kiện kích hoạt trong khi agent ngừng hoạt động, nó vẫn được xử lý
Sự kiện bị mất nếu process không chạy
Quan sát sau khi xảy ra
Xem những gì đã xảy ra sau đó: mọi bước, mọi quyết định, mọi lần retry
Logs là lựa chọn duy nhất của bạn và chúng phù du
Triển khai nóng không thời gian chết
Triển khai phiên bản function mới mà không giết các lần chạy đang diễn ra
Khởi động lại process giết chết mọi thứ
Kiểm soát đồng thời
Chỉ chạy N phiên bản của một skill tại một thời điểm
Không có nguyên thủy đồng thời tích hợp
"Chạy nó trong một container" giúp bạn có thời gian hoạt động. Nó không mang lại cho bạn sự chính xác. Một container khởi động lại sau sự cố đưa process trở lại, nhưng mọi loop đang diễn ra đều bắt đầu lại. Mọi bước thực thi lại. Mọi cuộc gọi LLM được thực hiện lại. Loop trông như đang chạy, nhưng nó đang chạy một cách mù quáng.
So sánh với các công cụ hiện có
Một số công cụ có thể cung cấp cho bạn một giải pháp "đẹp" cho loại hệ thống này hoặc bạn có thể chọn kết hợp một số công cụ cấp thấp hơn và tạo hệ thống của riêng bạn. Cả hai lựa chọn đều không sai, nhưng lớp kiến trúc phù hợp sẽ cho phép bạn, và agent của bạn, phát triển theo thời gian. Linh hoạt, năng động, bền vững.
Các nguyên thủy thực thi bền vững phù hợp tốt cho một agent, mà agent có thể dễ dàng viết, và khả năng quan sát và các API để quan sát và cho phép bản thân agent nhận thức được orchestration.
Một ví dụ hoạt động
Chúng tôi đang thử nghiệm các mẫu này nội bộ tại Inngest và bạn có thể thấy một khái niệm về điều này trong repo dự án "utah" tại đây: https://github.com/inngest/utah: Đó là một agent harness được xây dựng trên nền tảng orchestration bền vững của Inngest và cũng nhận thức được orchestration.
Hệ thống có một process sidecar cho phép agent chính viết và chỉnh sửa các function Inngest trong workspace của riêng nó, tự mở rộng với các "skill" (trong bối cảnh của bài viết này). Sớm thôi, chúng tôi dự định cung cấp toàn bộ hệ thống với các loops khởi đầu làm ví dụ, nhưng các ý tưởng ở đó có thể thể hiện các ý tưởng trong bài viết này rõ ràng hơn một chút.
Vòng lặp kết hợp
Bài đăng gần đây của Satya Nadella recent post đã đặt tên cho một điều mà ngành công nghiệp đang cảm nhận: hào không phải là mô hình — đó là loop.
Khung của ông ấy: có hai loại vốn. Vốn con người, kiến thức và phán đoán mà nhóm của bạn đã xây dựng trong nhiều năm. Và thứ ông ấy gọi là vốn token, các workflow AI, mẫu quyết định và kỹ năng đã học mà một công ty xây dựng trên các mô hình nền tảng.
Luận điểm: chúng kết hợp với nhau. Mỗi workflow được cải thiện tạo ra tín hiệu tốt hơn. Tín hiệu tốt hơn tạo ra hành vi AI sắc bén hơn. Hành vi sắc bén hơn giải phóng sự chú ý của con người cho công việc phán đoán cao hơn. Một cỗ máy leo đồi.
Đây là những gì kiến trúc agent loop cho phép một cách cụ thể:
- Mọi skill bền vững mà agent triển khai là kiến thức thể chế được mã hóa thành cơ sở hạ tầng có thể thực thi. Nó tồn tại. Nó chạy dù có người nhìn hay không.
- Một vòng lặp đánh giá kích hoạt cron để đánh giá hiệu suất skill và lặp lại. Đó chính là cỗ máy leo đồi được hiện thực hóa. Không phải một sơ đồ bánh đà trong một bài thuyết trình. Một function với một cron trigger.
- Nếu các skill của bạn chết khi process khởi động lại, sự kết hợp sẽ thiết lập lại về không. Durability là thứ làm cho khoản đầu tư tồn tại.
Điểm chính của Nadella: "Một công ty có thể chuyển đổi mô hình 'tổng quát' mà không mất đi chuyên môn 'kỳ cựu của công ty' được xây dựng trong hệ thống học tập của họ." Đó là mẫu thư viện skill. Các function bền vững không quan tâm LLM nào gọi chúng.
Xây dựng cho phù hợp
Cuộc trò chuyện đã xoay quanh những gì agent làm: loops, tools, lý luận, kỹ thuật ngữ cảnh. Cuộc trò chuyện tiếp theo là về những gì chạy các agent.
Ba lớp: loop, skill, orchestrator. Loop là đơn vị công việc. Skill là tài sản. Orchestration engine là thứ làm cho cả hai bền vững. Mẫu sidecar là mô hình: một agent viết các skill bền vững của riêng nó, triển khai chúng, đánh giá cách chúng hoạt động và lặp lại. Không phải một thí nghiệm suy nghĩ. Đó là một mô hình hoạt động.
Chúng tôi đã xây dựng Inngest để trở thành orchestration engine cho việc này: step.run(), step.invoke(), cron triggers, điều khiển luồng hướng sự kiện, kiểm soát đồng thời và khả năng quan sát đầy đủ cấp bước. Nhưng mẫu kiến trúc lớn hơn bất kỳ công cụ đơn lẻ nào. Nếu bạn đang xây dựng agent loops trong production, hãy xác định ba lớp.
Các nguyên thủy tồn tại ngày hôm nay. Xây dựng cho phù hợp.
