The Intelligence Isn't in the AI Agents, It's in the Arrows Between Them
โดย Nokka (นก-กา) | 16 สิงหาคม 2026
บทความนี้เขียนโดย AI (DeepSeek V4 Pro) ผ่าน Hermes Agent ภายใต้การควบคุมและตรวจสอบคุณภาพโดยมนุษย์, Nokka (นก-กา)
🇹🇭 ข้ามไปอ่านภาษาไทย · 🇬🇧 Read in English
English
A developer named Miraqle ran an experiment that quietly answers a question everyone in AI is arguing about wrong. He spun up twenty AI agents at once, wired them together with 340 connections, and let them work in parallel. Then he wrote one sentence that should be printed on every AI team's wall: "almost none of the intelligence lives in the agents. it lives in the arrows between them" [1].
That sentence is the whole point. But "the arrows" is a vague phrase, and if you do not know exactly what it means, the insight stays abstract. Let me make it concrete.
What "the arrows" actually are
An "arrow" is simply the rule that says which agent sends its result to which other agent. It is the routing of messages. When agent A finishes its job, does its output go to agent B, or to agent C, or back to a supervisor? That decision is one arrow.
Here is a concrete example. Imagine a coding system with three agents: a planner, a coder, and a tester. The arrows define the flow:
planner → coder → tester
↑ │
└────────┘ (failures route back to coder)
The planner writes a spec and sends it to the coder. The coder writes code and sends it to the tester. The tester runs it, and if it fails, the error goes back to the coder with the exact stack trace. This loop repeats until the tests pass [2].
Those arrows are the wiring. Change them, and the same three agents behave completely differently. If you wire the tester to send results to the planner instead of the coder, the coder never learns what broke. If you wire everyone to talk to everyone, you get a mess of 340 connections where nobody knows whose output to trust.
The experiment, explained simply
Miraqle did something clever. He took the same twenty agents, the same AI models, the same instructions, the same budget, and changed only one thing: who talks to whom. He redrew the arrows.
The result: the output went from "way better than a single agent" to "way worse than one." Nothing changed except the diagram [1].
| Setup | Result |
|---|---|
| One agent doing everything | Baseline |
| Twenty agents, good wiring | Way better than one agent |
| Twenty agents, bad wiring | Way worse than one agent |
Same people, same skills, same money. You only rearrange who reports to whom, and the whole team goes from brilliant to useless. The intelligence was never in the workers. It was in the wiring.
The five ways to draw the arrows
This is not just one person's opinion. The whole field of multi-agent orchestration has settled on a handful of standard wiring patterns, and each one is a different way of drawing the arrows [2]:
Orchestrator-worker. One supervisor sits on top and fans work out to many workers, then collects their results. This is the pattern Miraqle recommends: "a supervisor over the fan-out" [1]. It is the most common pattern in production because it is easy to reason about. The trade-off: the supervisor is a single point of failure and a bottleneck.
Swarm. No central boss. Each agent has a set of skills and hands a task off to another agent when it hits something outside its specialty. OpenAI's Swarm framework popularized this. It scales well but is hard to debug, because nobody is in charge of deciding when the job is done.
Mesh. Every agent talks directly to every other agent. This is the "340 connections" Miraqle described, and it is usually the bad wiring. Connections grow as N-squared, so twenty agents means hundreds of arrows and a coordination mess.
Hierarchical. A tree. A top manager delegates to mid-level supervisors, who delegate to leaf workers. This mirrors how big companies work, but latency and information loss accumulate at every level.
Pipeline. A straight line. Each agent's output feeds the next, like an assembly line. Predictable, but one broken stage blocks everything.
The key insight from the research: you can have the best model in the world, but if you wire it into a suboptimal topology, you get suboptimal results [3]. The topology, the arrows, is a first-class design decision, not an afterthought.
Why this matters more than the model wars
Right now, most of the AI world is arguing about which model is best. Grok versus the next one. Bigger, faster, smarter. Miraqle's point is that this argument is missing the real lever.
The people quietly winning stopped picking models and started drawing graphs. They use a few boring patterns that decide everything [1]:
A supervisor over the fan-out. One agent coordinates the rest, instead of everyone talking to everyone.
One job, one output per worker. Each agent does exactly one thing and hands back exactly one result.
A lone control agent that checks whether the crew is even earning its cost.
These are not glamorous. They are plumbing. But they decide the whole result.
The honest counterpoint
To be fair, this is not a universal law. A single strong model doing one focused job can still beat a badly wired team, and multi-agent setups add real overhead: more tokens, more latency, more places to fail. The point is not that more agents are always better. The point is that if you do go multi-agent, the wiring, not the model, is what decides whether it helps or hurts.
What this means for you
If you are building anything with AI, stop asking "which model should I use" and start asking "how should these pieces talk to each other." The model is the easy decision. The wiring is the hard one, and it is the one that actually moves the result.
The good news: tools like Grok Bot now let you spin up a whole multi-agent crew with a single message. The diagram is the only hard part left. And that is exactly where the winners are looking.
ภาษาไทย
นักพัฒนาคนหนึ่งชื่อ Miraqle รันการทดลองที่ตอบคำถามที่ทุกคนในวงการ AI กำลังเถียงกันผิดประเด็นอย่างเงียบๆ เขาปั่น AI agent ขึ้นมา 20 ตัวพร้อมกัน เชื่อมมันเข้าด้วยกันด้วย 340 เส้นเชื่อม แล้วปล่อยให้ทำงานคู่ขนาน จากนั้นเขาเขียนประโยคหนึ่งที่ควรพิมพ์แปะไว้บนผนังของทีม AI ทุกทีม: "ความฉลาดแทบทั้งหมดไม่ได้อยู่ในตัว agent แต่มันอยู่ในลูกศรที่เชื่อมระหว่างมัน" (almost none of the intelligence lives in the agents. it lives in the arrows between them) [1]
ประโยคนั้นคือใจความทั้งหมด แต่คำว่า "ลูกศร" มันคลุมเครือ และถ้าคุณไม่รู้ว่ามันหมายถึงอะไรจริงๆ ข้อคิดนี้ก็จะลอยๆ อยู่แบบนั้น ขอทำให้มันจับต้องได้
"ลูกศร" จริงๆ แล้วคืออะไร
"ลูกศร" ก็คือกฎที่บอกว่า agent ตัวไหนส่งผลงานให้ agent ตัวไหนต่อ มันคือเส้นทางการส่งข้อความ เมื่อ agent A ทำงานเสร็จ ผลลัพธ์ของมันจะไปหา agent B หรือ agent C หรือกลับไปหา supervisor? การตัดสินใจนั้นคือลูกศรหนึ่งเส้น
นี่คือตัวอย่างจริง ลองนึกถึงระบบเขียนโค้ดที่มี agent 3 ตัว: ตัววางแผน (planner), ตัวเขียนโค้ด (coder), ตัวทดสอบ (tester) ลูกศรกำหนดการไหลแบบนี้:
planner → coder → tester
↑ │
└────────┘ (ถ้าพัง ส่งกลับไปให้ coder)
planner เขียนสเปกแล้วส่งให้ coder coder เขียนโค้ดแล้วส่งให้ tester tester รันแล้วถ้าพัง ก็ส่ง error กลับไปให้ coder พร้อม stack trace ครบ วนแบบนี้จนกว่าจะผ่าน [2]
ลูกศรพวกนั้นคือการเดินสาย เปลี่ยนมัน แล้ว agent 3 ตัวเดิมจะทำงานต่างกันสิ้นเชิง ถ้าคุณเดินสายให้ tester ส่งผลให้ planner แทนที่จะส่งให้ coder coder ก็ไม่มีทางรู้ว่าอะไรพัง ถ้าคุณให้ทุกคนคุยกับทุกคน คุณก็จะได้ความยุ่งเหยิง 340 เส้นเชื่อมที่ไม่มีใครรู้ว่าควรเชื่อผลของใคร
การทดลอง อธิบายง่ายๆ
Miraqle ทำเรื่องฉลาด เขาใช้ agent 20 ตัวเดิม โมเดล AI เดิม คำสั่งเดิม งบประมาณเดิม แล้วเปลี่ยนแค่สิ่งเดียว: ใครคุยกับใคร เขาวาดลูกศรใหม่
ผลลัพธ์: ผลงานเปลี่ยนจาก "ดีกว่า agent ตัวเดียวมาก" ไปเป็น "แย่กว่า agent ตัวเดียว" ไม่มีอะไรเปลี่ยนเลยนอกจากแผนผัง [1]
| การจัดทีม | ผลลัพธ์ |
|---|---|
| agent ตัวเดียวทำทุกอย่าง | จุดอ้างอิง |
| 20 ตัว เดินสายดี | ดีกว่าตัวเดียวมาก |
| 20 ตัว เดินสายแย่ | แย่กว่าตัวเดียว |
คนเดิม ทักษะเดิม เงินเท่าเดิม คุณแค่จัดใหม่ว่าใครรายงานใคร แล้วทั้งทีมก็เปลี่ยนจากเก่งเป็นไร้ประโยชน์ ความฉลาดไม่เคยอยู่ในตัวคนงาน แต่มันอยู่ในการเดินสาย
5 วิธีวาดลูกศร
นี่ไม่ใช่ความเห็นของคนคนเดียว วงการ multi-agent orchestration ทั้งหมดตกผลึกเป็นแพตเทิร์นการเดินสายมาตรฐานไม่กี่แบบ และแต่ละแบบคือวิธีวาดลูกศรที่ต่างกัน [2]:
Orchestrator-worker มี supervisor ตัวเดียวนั่งบนสุด แล้วกระจายงานออกไปให้ worker หลายตัว แล้วเก็บผลกลับมา นี่คือแพตเทิร์นที่ Miraqle แนะนำ: "supervisor อยู่เหนือ fan-out" [1] เป็นแพตเทิร์นที่ใช้บ่อยสุดในระบบจริงเพราะเข้าใจง่าย ข้อเสียคือ supervisor เป็นจุดล้มเหลวจุดเดียวและเป็นคอขวด
Swarm ไม่มีหัวหน้า แต่ละ agent มีชุดทักษะ และส่งต่องานให้ agent ตัวอื่นเมื่อเจองานนอกความถนัด OpenAI Swarm framework ทำให้แพตเทิร์นนี้ดัง มันขยายตัวได้ดีแต่ debug ยาก เพราะไม่มีใครรับผิดชอบตัดสินว่างานเสร็จเมื่อไหร่
Mesh ทุก agent คุยกับทุก agent โดยตรง นี่คือ "340 เส้นเชื่อม" ที่ Miraqle พูดถึง และมันมักคือการเดินสายที่แย่ เส้นเชื่อมโตแบบ N กำลังสอง 20 ตัวแปลว่าเส้นเชื่อมเป็นร้อยและความยุ่งเหยิงในการประสานงาน
Hierarchical เป็นต้นไม้ ผู้จัดการระดับบนมอบหมายให้ supervisor ระดับกลาง แล้วมอบหมายต่อให้ worker ระดับล่าง เหมือนวิธีที่บริษัทใหญ่ทำงาน แต่ latency และการสูญเสียข้อมูลสะสมทุกชั้น
Pipeline เส้นตรง ผลลัพธ์ของแต่ละ agent ป้อนให้ตัวถัดไป เหมือนสายพานการผลิต คาดเดาได้ แต่พังจุดเดียวก็บล็อกทั้งสาย
ข้อคิดสำคัญจากงานวิจัย: คุณมีโมเดลที่ดีที่สุดในโลกก็จริง แต่ถ้าเดินสายมันเข้ากับ topology ที่ไม่ดี คุณก็ได้ผลลัพธ์ที่ไม่ดี [3] topology หรือลูกศร คือการตัดสินใจออกแบบระดับแรก ไม่ใช่เรื่องที่ค่อยคิดทีหลัง
ทำไมเรื่องนี้สำคัญกว่าสงครามโมเดล
ตอนนี้ วงการ AI ส่วนใหญ่กำลังเถียงกันว่าโมเดลไหนดีที่สุด Grok หรือตัวถัดไป ใหญ่กว่า เร็วกว่า ฉลาดกว่า ประเด็นของ Miraqle คือการเถียงนี้พลาดคันโยกที่แท้จริง
คนที่ชนะอย่างเงียบๆ เลิกเลือกโมเดล แล้วเริ่มวาดกราฟ พวกเขาใช้แพตเทิร์นน่าเบื่อไม่กี่อย่างที่ตัดสินทุกอย่าง [1]:
มี supervisor อยู่เหนือ fan-out ตัวหนึ่งคอยประสานตัวที่เหลือ แทนที่จะให้ทุกคนคุยกับทุกคน
หนึ่งงาน หนึ่งผลลัพธ์ ต่อ worker หนึ่งตัว แต่ละ agent ทำสิ่งเดียวเป๊ะ แล้วส่งผลลัพธ์กลับชิ้นเดียว
มี control agent ตัวเดียวที่คอยเช็คว่าทีมนี้ "คุ้มค่าใช้จ่าย" จริงไหม
สิ่งเหล่านี้ไม่หรูหรา มันคืองานประปา แต่พวกมันตัดสินผลลัพธ์ทั้งหมด
มุมสมดุลที่ต้องพูดตรงๆ
พูดตามตรง นี่ไม่ใช่กฎสากล โมเดลตัวเดียวที่เก่งและทำงานโฟกัสชิ้นเดียว ก็ยังชนะทีมที่เดินสายแย่ได้ และ multi-agent เพิ่ม overhead จริง: token มากขึ้น, latency มากขึ้น, จุดที่พังได้มากขึ้น ประเด็นไม่ใช่ว่า "agent เยอะกว่าดีกว่าเสมอ" แต่คือถ้าคุณจะใช้ multi-agent การเดินสาย ไม่ใช่โมเดล คือตัวตัดสินว่ามันช่วยหรือทำร้าย
สิ่งนี้หมายถึงอะไรสำหรับคุณ
ถ้าคุณกำลังสร้างอะไรด้วย AI เลิกถาม "ควรใช้โมเดลไหน" แล้วเริ่มถาม "ชิ้นส่วนพวกนี้ควรคุยกันยังไง" โมเดลคือการตัดสินใจที่ง่าย การเดินสายคือส่วนที่ยาก และมันคือส่วนที่ขยับผลลัพธ์จริงๆ
ข่าวดี: เครื่องมืออย่าง Grok Bot ตอนนี้ให้คุณปั่นทีม multi-agent ทั้งทีมด้วยข้อความเดียว แผนผังคือส่วนที่ยากเพียงอย่างเดียวที่เหลือ และนั่นคือจุดที่ผู้ชนะกำลังมองอยู่
References
[1] Miraqle (@0xMiraqle). "GROK BOT IN GOD MODE - 20-agent run...". X (Twitter). 16 ส.ค. 2026. https://x.com/0xMiraqle/status/2088782463824793839
[2] Víctor Mollá. "Agent Orchestration Patterns: Swarm vs Mesh vs Hierarchical vs Pipeline". GuruSup. 2 พ.ค. 2026. https://gurusup.com/blog/agent-orchestration-patterns
[3] Sun Changsheng. "When Graphs Meet Agents: Orchestration, Topology, and the Uncharted Territory of Safety". 9 ก.พ. 2026. https://sunchangsheng.com/blog/2026-02-09-graph-agent.html
บทความนี้วิเคราะห์จากโพสต์ X ของ Miraqle (@0xMiraqle), GuruSup (orchestration patterns), และงานวิจัย topology ของ multi-agent ข้อมูล ณ 16 สิงหาคม 2026 Nokka
ผมชอบโพสต์นี้มาก เพราะมันพูดเรื่องที่วงการ AI ไม่ค่อยกล้าพูด: "คุณกำลังเถียงเรื่องโมเดล แต่ตัวตัดสินผลลัพธ์คือการเดินสาย" มันตรงกับที่ผมเขียนเรื่อง Google + MIT multi-agent ไปก่อนหน้านี้ ว่าการเปลี่ยนแค่ "ใครคุยกับใคร" ก็พลิกผลลัพธ์จากแย่กว่า 70% เป็นดีกว่า 80% ได้
ถ้าคุณเคยลองใช้ multi-agent แล้วรู้สึกว่ามันไม่เวิร์ก ลองกลับไปดูแผนผังของคุณก่อน อย่าโทษโมเดล บอกผมในคอมเมนต์ได้ว่าคุณเจอปัญหาอะไรกับการจัดทีม AI ครับ
Top comments (0)