ชั้นข้อมูลที่ขาดหาย: การสร้างโครงสร้าง AI Agents สำหรับลำดับชั้นขององค์กร

โมเดลอ้างอิงสำหรับวิธีที่องค์กรจัดโครงสร้างการทำงานร่วมกับ AI

Jose Martinez · 1 ตุลาคม 2026 · v1.8.1 (วัดผลใน Claude Code; ตรวจสอบซ้ำกับเอกสารของ Anthropic เมื่อวันที่ 1 ตุลาคม 2026)

สรุปในห้าบรรทัด

1. องค์กรคือโครงสร้างต้นไม้: บริษัท, สายงาน, โปรเจกต์, งาน แต่โปรเจกต์ของ Claude เป็นแบบแบนราบ: แชทมีบล็อกข้อมูลองค์กรเพียงก้อนเดียวขนาด 3,000 ตัวอักษร โปรเจกต์ในแชทและ Cowork ไม่สามารถซ้อนชั้นหรือสืบทอดกันได้ และในโปรเจกต์หนึ่งๆ บัญชี connector จะผูกกับบุคคลใดบุคคลหนึ่งหรือกับทั้งองค์กรเท่านั้น ไม่เคยผูกกับกิ่งย่อยใดๆ เลย

1. ผลก็คือ ทุกโปรเจกต์ต้องคัดลอกกฎของสายงานมาใส่เองด้วยมือ เมื่อเวลาผ่านไปสำเนาเหล่านั้นก็เริ่มผิดเพี้ยนไปจากต้นฉบับ และไม่มีใครมองเห็นเลยว่าคำตอบที่ได้มานั้นมาจากกฎข้อไหน

1. Anthropic สร้างโครงสร้างต้นไม้นี้มาแล้วสองครั้ง ใน Claude Code จะซ้อนคำสั่งตามโฟลเดอร์ และตั้งแต่วันที่ 1 ตุลาคม 2026 เป็นต้นมา ระบบจะรัน mod ขององค์กรก่อน mod ของบุคคล ส่วน Claude Tag ใน Slack จะสืบทอดคำสั่งและข้อมูลรับรองสิทธิ์จากระดับองค์กร ไปยัง workspace และ channel แต่ไม่มีตัวไหนเข้าถึงระดับโปรเจกต์เลย โมเดลเดียวกันนี้ทำได้โดยเพิ่มเลเยอร์สายงาน ให้โปรเจกต์ถูกสร้างจากโฟลเดอร์ของสายงานนั้น มี task ที่ระบุประเภทชัดเจน มี compiler ที่ดักปฏิเสธความขัดแย้งก่อนที่โมเดลจะเห็น และมีระบบสิทธิ์แบบรายโหนดที่ใช้งานได้บนแผน Team

1. ผมทดสอบเรื่องนี้ใน Claude Code ถึงสองรอบ โดยใช้กฎองค์กรและกฎโปรเจกต์ที่ขัดแย้งกัน วางไว้ในไฟล์ CLAUDE.md คนละระดับ และไม่ได้ระบุว่าอันไหนมีผลบังคับ: กฎโปรเจกต์ชนะทั้ง 20 ครั้งจาก 20 ครั้ง แต่เมื่อกำหนดให้กฎองค์กรมีผลบังคับด้วยข้อความ: กฎองค์กรชนะทั้ง 20 ครั้งจาก 20 ครั้ง ลำดับความสำคัญถูกกำหนดด้วยถ้อยคำที่ใครก็ตามที่แก้ไขเลเยอร์ไหนก็เปลี่ยนได้ ไม่ใช่กำหนดด้วยโครงสร้าง

1. มันใช้งานได้แล้ววันนี้ แอปเดสก์ท็อปที่ผมสร้างขึ้นมารัน Claude Code อยู่ภายในโครงสร้างต้นไม้นี้ โดย mount แต่ละเลเยอร์เป็นไฟล์ CLAUDE.md จำกัดสิ่งที่ Claude ทำได้ตามสิทธิ์ของบุคคลในโหนดนั้น ปฏิเสธความขัดแย้งตั้งแต่ตอนเขียน และบันทึก log ทุกคำตอบพร้อมกฎที่ใช้ จำนวน token และผู้ตรวจสอบ เมื่อนำมาวัดผล โครงสร้างต้นไม้ใช้ instruction token น้อยกว่าการคัดลอกแบบแบนราบถึง 20–34%

องค์กรคือโครงสร้างต้นไม้ บริษัทกำหนดนโยบาย สายงานกำหนดมาตรฐาน โปรเจกต์นำมาตรฐานมาใช้กับงานแต่ละชิ้น และ task ส่งมอบผลลัพธ์หนึ่งอย่าง ระบบควบคุมคุณภาพทุกแห่งที่ผมเคยทำงานด้วยล้วนสร้างขึ้นมาแบบนี้ รวมถึงโครงสร้างโฟลเดอร์บน file server ของแทบทุกบริษัท: บริษัท, สายงาน, ปี, แล้วตามด้วยโฟลเดอร์หนึ่งโฟลเดอร์ต่องานหนึ่งชิ้น ตั้งชื่อด้วยหมายเลขงานที่เข้ารหัสข้อมูลทั้งหมดไว้ข้างใน

แต่โปรเจกต์ AI กลับแบนราบ ผมยกตัวอย่างกรณีศึกษาด้วย Claude เพราะเป็นผลิตภัณฑ์ที่ผมใช้งานทุกวัน และเป็นเพราะมันส่งมอบคำตอบนี้มาแล้วในสอง interface ของตัวเอง ในแชทของ Claude โปรเจกต์ไม่สามารถซ้อนชั้นกันได้ และคำสั่งระดับองค์กรเป็นเพียงบล็อกข้อความเดียวยาวไม่เกิน 3,000 ตัวอักษรที่ใช้กับทุกคน บนแผน Enterprise ผู้ดูแลระบบสามารถกำหนดขอบเขต permissions ตามกลุ่มได้ แต่บนแผน Team บทบาทจะถูกใช้กับทั้งองค์กร ไม่มีอะไรที่ถูกบันทึกไว้ในแชทหรือ Cowork ที่จะส่งต่อ instructions ลงไปยังแผนกหรือสายงาน และลงลึกไปถึงโปรเจกต์ของมันได้ บนแผน Enterprise สามารถแชร์ skills และโปรเจกต์กับกลุ่มได้ แต่นั่นคือการแจกจ่าย ไม่ใช่การสืบทอด

นั่นคือเลเยอร์ที่ขาดหายไป: เลเยอร์ที่อยู่ระหว่างองค์กรกับโปรเจกต์ บทความนี้จะอธิบายว่าอะไรที่ขาดหายไป ทำไมมันจึงสำคัญ ต้นทุนที่แท้จริงคืออะไร พร้อมเสนอโมเดลอ้างอิงที่แพลตฟอร์มใดก็นำไปใช้ได้ รวมถึงระบบสิทธิ์และโครงสร้างข้อมูลของมัน

1. สิ่งที่มีอยู่ในปัจจุบัน

ตรวจสอบเทียบกับเอกสารของ Anthropic ระหว่างวันที่ 29 กันยายน – 1 ตุลาคม 2026 Claude มี 4 interfaces ที่ทีมงานใช้ทำงาน และแต่ละตัวก็มีโมเดลคำสั่งของตัวเอง:

สิทธิ์การใช้งานขึ้นอยู่กับแผนที่เลือก:

Anthropic สร้างโครงสร้างต้นไม้สำหรับ permissions มาแล้วครึ่งหนึ่ง บนแผน Enterprise มีการกำหนด custom roles ให้กับกลุ่มต่างๆ "custom roles ยังควบคุมได้ว่าบทบาทนั้นจะใช้ connectors ตัวไหน และ tools ใดบน connectors เหล่านั้นได้บ้าง" ทั่วทั้งแพลตฟอร์ม ทั้งในระดับองค์กร ระดับบทบาท และระดับผู้ใช้ "ระดับที่เข้มงวดที่สุดจะเป็นผู้ชนะ" ในขณะที่บทบาทหลายอย่างของสมาชิกคนหนึ่งจะถูกรวมเข้าด้วยกัน ผู้ดูแลระบบสามารถ "View effective role" ได้พร้อมป้ายกำกับ "Granted by" และกลุ่มต่างๆ สามารถมีวงเงินใช้จ่ายของตัวเองได้ แต่นี่เป็นเพียงกลุ่มแบบแบนราบ ไม่ใช่โครงสร้างต้นไม้ และไม่มีส่วนใดเข้าถึง instructions เลย สิ่งที่ใกล้เคียงที่สุดคือ plugins: บนแผน Enterprise เจ้าของระบบสามารถตั้งค่า plugin และ skills ของมันให้เป็นสิ่งจำเป็นหรือติดตั้งเริ่มต้นให้กับกลุ่มใดกลุ่มหนึ่งได้ พร้อมลำดับที่ระบุไว้อย่างชัดเจน ("group setting, then org-wide setting, then marketplace default") ซึ่งมุ่งเป้าไปที่กลุ่มคน ไม่ใช่โปรเจกต์ ไม่มีอะไรสืบทอดระหว่างโปรเจกต์ และ skill จะโหลดก็ต่อเมื่อ Claude เห็นว่ามันเกี่ยวข้องเท่านั้น แผน Team มีบทบาทสำหรับทั้งองค์กรและการแชร์แบบรายบุคคล การตั้งค่า plugin ของแผน Team นั้น ตามคำในเอกสารระบุว่า "no group setting" และแผน Team ก็คือแผนที่ออกแบบมาเพื่อธุรกิจขนาดเล็กและขนาดกลางโดยเฉพาะ

Anthropic สร้างโครงสร้างต้นไม้ที่สมบูรณ์มาแล้วสองครั้ง แต่นอกเหนือจากโปรเจกต์

ใน Claude Code แบ่งตามโฟลเดอร์ Claude Code โหลดไฟล์ CLAUDE.md จากสี่ระดับ "ไฟล์ทั้งหมดที่ค้นพบจะถูกนำมาต่อกันเป็น context แทนที่จะเขียนทับกัน" เรียงลำดับ "จากรากของ filesystem ลงมายัง working directory ของคุณ" และไฟล์ในโฟลเดอร์ย่อยจะ "load on demand" บล็อกขององค์กรอาจถูกส่งมาเป็น managed file บนเครื่องแต่ละเครื่อง หรือมาเป็นข้อความจาก admin console (คีย์ claudeMd) เอกสารระบุข้อจำกัดไว้อย่างตรงไปตรงมา: Claude มองไฟล์เหล่านี้ "as context, not enforced configuration" และ "if two instructions contradict each other, Claude may pick one arbitrarily."

ใน Claude Tag แบ่งตาม channel ของ Slack Claude Tag คือ Claude ที่อยู่ใน Slack ของทีม เปิด public beta บนแผน Team และ Enterprise การตั้งค่าของมันจะผูกกับ scope และ "scope คือจุดที่ bundle ถูกนำไปใช้: Default Slack access (รากที่ครอบคลุมทั้งองค์กร), workspace หรือ channel เดียว" สามสิ่งที่บทความที่เหลือนี้เรียกร้องให้มีนั้น แท้จริงแล้วมีอยู่แล้ว:

• Instructions สืบทอดกันได้ "Per-scope custom instructions are concatenated, Default Slack access first, then workspace, then channel. A channel's instructions add to, rather than replace, what's set above it."

• Credentials เป็นของกิ่งนั้นๆ ใน channel ต่างๆ Claude จะทำงานด้วย service accounts ที่ผู้ดูแลระบบผูกไว้กับ scope และ "the credential from the narrowest scope is used: channel beats workspace, which beats Default Slack access."

• คุณสามารถดูได้ว่าสิทธิ์มาจากไหน แถวของ connector, repository และ plugin แต่ละตัวจะระบุว่า "Inherited from" scope ที่กว้างกว่า หรือ "Attached from" bundle ใด วงเงินใช้จ่ายถูกจำกัดทั้งระดับองค์กรและราย channel และมีการรายงานแยกตาม channel

ข้อจำกัดก็ถูกระบุไว้ในเอกสารเช่นกัน โครงสร้างต้นไม้นี้มีรูปร่างตาม Slack: มีสามระดับที่ตายตัว และ channel ของ Slack ซ้อนกันไม่ได้ Instructions เป็นเพียง "guidance, not an enforced guardrail" และเอกสารไม่ได้อธิบายถึงการตรวจสอบความขัดแย้งระหว่าง scope ไว้เลย "no per-action log of every task and who asked" และมันหยุดอยู่แค่ขอบของโปรเจกต์: "Projects in claude.ai don't apply here; Claude doesn't read a Project's instructions or knowledge in Slack, and a channel can't be pointed at a Project."

สิ่งที่เปลี่ยนแปลงในวันที่ 1 ตุลาคม 2026 Claude Code 2.1.287 เปิดใช้งาน mods ซึ่งก่อนหน้านี้เปิดให้ทดลองใช้แบบ early access: มันคือฟังก์ชันภายใน plugin ที่รันอยู่ข้างใน Claude Code และสามารถ rewrite prompt หรือบางส่วนของ system prompt, บล็อกหรือ rewrite การเรียกใช้ tool, อนุมัติหรือปฏิเสธคำขอสิทธิ์ และวาด pane ใน interface ได้ มีสามเรื่องเกี่ยวกับ mods ที่สำคัญในบริบทนี้:

• พวกมันมีลำดับที่ประกาศไว้อย่างชัดเจน built-in guard และ mod ขององค์กรจะรันก่อน จากนั้นจึงเป็น mod ที่บุคคลติดตั้งลงไป "The first mod is outermost: it sees the event before the others and the result after them, and it decides whether the others run at all." ในจุดที่ guard โหลด (เครื่องที่มีการตั้งค่าแบบ managed หรือการเข้าสู่ระบบผ่าน Team หรือ Enterprise) mod ของบุคคลจะไม่สามารถเปลี่ยน "the system prompt, your managed CLAUDE.md and other managed instructions" ได้ และไม่สามารถอนุมัติการเรียกใช้ tool ที่ deny rule ปฏิเสธไปได้ นี่คือลำดับความสำคัญที่กำหนดด้วยโครงสร้าง ซึ่งเป็นสิ่งที่บทความนี้เรียกร้อง มันเป็นค่าเริ่มต้น ไม่ใช่กุญแจล็อค: บุคคลที่เริ่มใช้งาน Claude Code ด้วย --safe-mode จะรันโดยไม่ใช้ mod ที่ติดตั้งไว้ รวมถึงขององค์กรด้วย ในขณะที่ managed hooks และ deny rules ยังคงมีผลบังคับ

• ลำดับนี้มีเจ้าของสองฝ่าย mod ขององค์กรรันก่อน mod ของบุคคล หรือรันทีหลังหากองค์กรเลือกเช่นนั้น ไม่มีระดับสำหรับสายงาน การตั้งค่าที่ส่งมาจาก admin console "apply uniformly to all users in the organization. Per-group configurations are not yet supported." องค์กรที่ต้องการนโยบายต่างกันในแต่ละกลุ่มมีสองทางเลือก ซึ่งทั้งคู่ต้องผ่านฝ่าย IT: deploy ไฟล์ตั้งค่าที่แตกต่างกันไปยังเครื่องของแต่ละกลุ่ม หรือรัน self-hosted gateway ที่ "delivers managed settings per IdP group"

• พวกมันเข้าไม่ถึงแชท และเข้าถึง Cowork แบบไม่สม่ำเสมอ "Mods work in the Claude Code CLI and in the Code tab of the Claude Desktop app." mod ถูกส่งมาใน hooks/hooks.json ของ plugin และตารางรองรับ plugin ของ Anthropic ระบุว่าไฟล์นี้ "Ignored" ในแชท ตารางเดียวกันระบุว่า "Loads" ใน Cowork เพราะ "Cowork in the Claude Desktop app runs its sessions on Claude Code"; หน้าเอกสารเกี่ยวกับ mods ไม่ได้ระบุถึง Cowork ไว้ และผมยังไม่ได้ทดสอบมัน สิ่งที่องค์กรควบคุมได้ในนั้นมีน้อยกว่า: ในเซสชัน Cowork นั้น Claude Code "never fetches server-managed settings from the claude.ai admin console, even when the user signs in with a Team or Enterprise account" และเซสชัน Cowork แบบ remote ก็ไม่มี device policy ให้อ่าน

สิ่งที่กำลังทยอยเปิดตัว Cowork กำลังถูกรวมเข้ากับ Claude: ศูนย์ช่วยเหลือระบุว่า "Claude Cowork is now just Claude" โดยเริ่มที่แผน Pro และ Max ก่อน ในขณะที่แผน Team และ Enterprise "keep chat and Claude Cowork as they are today" ในวันที่ 6 ตุลาคม 2026 task ใหม่ของ Cowork บนแผน Pro และ Max จะย้ายขึ้นคลาวด์ และโปรเจกต์เวอร์ชันใหม่กำลังเปิด public beta บนแผน Pro และ Max โดยเริ่มที่ Claude Code ก่อน แล้วตามด้วยแชท, Cowork, Team และ Enterprise ในเวอร์ชันนี้ "a project is one conversation" ที่ Claude จะแบ่งออกเป็น thread ย่อยแบบขนาน แต่มันก็ยังเป็นระดับเดียวอยู่ดี: "A project belongs to one user" และ "there are no organization-level controls for projects during the beta."

ดังนั้นโครงสร้างต้นไม้จึงไม่ใช่แนวคิดใหม่สำหรับ Anthropic มันมีอยู่แล้วในรูปแบบโฟลเดอร์สำหรับโค้ด และรูปแบบ channel สำหรับ Slack และในทั้งสองกรณีองค์กรจะมาก่อนเสมอ แต่สถานที่ที่บริษัทใช้เก็บงานของตน นั่นคือโปรเจกต์ กลับไม่มีทั้ง parent และสายงานอยู่เบื้องบน ผลิตภัณฑ์อีกสองตัวของ Anthropic ก็ชี้ไปในทิศทางเดียวกันแต่นอกเหนือขอบเขตของบทความนี้: Claude for Government แก้ไขการตั้งค่าผ่านลำดับ tenant, group และ organization และ Claude Desktop บน third-party providers มีนโยบายแบบรายกลุ่มในเวอร์ชัน beta

2. ทำไมเรื่องนี้จึงสำคัญ

โปรเจกต์ไม่ใช่ container งานจริงๆ ต่างหากที่เป็น container มันมี key (หมายเลขงาน), parent (สายงาน), lifecycle (เปิด, ปิด, จัดเก็บตามปี), โฟลเดอร์, ลูกค้า, บุคลากร, กฎ และ deliverables แต่โปรเจกต์ของ Claude มีเพียงชื่อแบบ free-text ไม่มี key, ไม่มี parent และไม่มี children และ lifecycle ที่ระบุไว้ในเอกสารก็คือการจัดเก็บและการลบ Cowork สามารถผูกโปรเจกต์กับโฟลเดอร์ในเครื่องได้ แต่ต้องทำด้วยมือ ทีละโปรเจกต์ ไม่มีรูปแบบ key และไม่มี parent สายงานหนึ่งอาจเปิดงานหลายร้อยชิ้นต่อปี ซึ่งทิ้งทางเลือกแย่ๆ ไว้สองทาง: สร้างโปรเจกต์ Claude ด้วยมือหนึ่งโปรเจกต์ต่องานหนึ่งชิ้น โดยแต่ละโปรเจกต์มีสำเนากฎของตัวเอง หรือสร้างหนึ่งโปรเจกต์ต่อสายงาน ซึ่ง context ของลูกค้าที่แตกต่างกันจะวางอยู่เคียงข้างกัน

เส้นทางการรับน้ำหนักขาดตอน ในงานวิศวกรรมโครงสร้าง น้ำหนักบรรทุกทุกจุดต้องมีเส้นทางต่อเนื่องลงไปยังฐานราก หากดึงองค์ประกอบหนึ่งออก ทุกอย่างที่อยู่เหนือมันจะไม่ถูกถ่ายเทลงมา กฎเกณฑ์ก็ทำงานแบบเดียวกัน เมื่อไม่มีเลเยอร์ระหว่างองค์กรกับโปรเจกต์ มาตรฐาน เทมเพลต และกฎการอนุมัติของสายงานจะไม่มีที่อยู่ ดังนั้นทุกโปรเจกต์จึงต้องคัดลอกมาใส่เองด้วยมือ

สำเนาเริ่มผิดเพี้ยน เมื่อแก้กฎในโปรเจกต์หนึ่ง โปรเจกต์อื่นๆ ก็ยังคงใช้เวอร์ชันเก่าต่อไป แต่ละโปรเจกต์ยังผ่านการตรวจสอบเฉพาะที่ของตัวเอง ความไม่สอดคล้องกันจะปรากฏขึ้นก็ต่อเมื่อมีคนนำโปรเจกต์มาเทียบกันแบบเคียงข้าง ซึ่งในงานที่ต้องอยู่ภายใต้กฎระเบียบมักจะเป็นผู้ตรวจสอบ ทีม Infrastructure รู้จักความล้มเหลวนี้ดี จากการวิจัยของ Firefly ในปี 2026 ประมาณหนึ่งในสามของผู้ตอบแบบสอบถามเชื่อมโยง configuration drift เข้ากับ incident ใน production ที่สร้างความเสียหายสูง และประมาณหนึ่งในห้าไม่มีกระบวนการตรวจจับหรือแก้ไขปัญหานี้

Identity ก็แบนราบเช่นกัน หลายคนทำงานข้ามมากกว่าหนึ่งองค์กร และแต่ละองค์กรต้องการ context ที่ปิดผนึกเป็นของตัวเอง ภายในองค์กรใดองค์กรหนึ่ง ทั้งในแชทและ Cowork บัญชี connector จะเป็นของบุคคล ไม่ใช่ของกิ่งสาขา บทบาทในแผน Enterprise สามารถกำหนดได้ว่ากลุ่มใดใช้ connector ตัวไหนได้บ้าง และผู้ดูแลระบบสามารถอนุญาต connector เพียงครั้งเดียวสำหรับทั้งองค์กรได้ แม้แต่ custom connector ก็สามารถพกพาข้อมูลรับรองสิทธิ์ที่แชร์ร่วมกันสำหรับทุกคนได้ (ในเวอร์ชัน beta) ไม่ว่าจะด้วยวิธีใด บัญชีก็เป็นของบุคคลหรือขององค์กร ไม่เคยเป็นของกิ่งสาขาเลย: ที่ปรึกษาที่ดูแลลูกค้าสองรายไม่สามารถผูก Drive ของลูกค้าแต่ละรายเข้ากับโปรเจกต์ของลูกค้ารายนั้นได้ โปรเจกต์แบบแชร์ทำให้ปัญหานี้ชัดขึ้นอีก: "Connectors are only available in private projects." Claude Tag แสดงให้เห็นว่าการออกแบบอีกแบบหนึ่งเป็นไปได้ ด้วยการผูก service account เข้ากับ channel ของ Slack และยังแสดงให้เห็นว่ามันหยุดอยู่ที่ใด นั่นคือที่โปรเจกต์ หน้าเอกสารเกี่ยวกับ Google connector ของ Anthropic อธิบายถึงบัญชี Google ที่เชื่อมต่อเพียงบัญชีเดียว และวิธีที่ระบุไว้ในการเปลี่ยนคือการตัดการเชื่อมต่อแล้วเชื่อมต่อใหม่ ประเด็นที่เปิดค้างอยู่สามรายการ (ด้านล่าง) เรียกร้องให้มีมากกว่าหนึ่งบัญชี ขอบเขตนี้ดำรงอยู่แค่ในหัวของคน ซึ่งก็คือขอบเขตแบบ manual ประเภทที่ล้มเหลวโดยไม่มีใครสังเกตเห็นนั่นเอง

ไม่มีใครมองเห็นว่ากฎข้อไหนถูกนำมาใช้ Claude Enterprise แสดง "View effective role" สำหรับ permissions ให้ผู้ดูแลระบบเห็น และ /context ของ Claude Code ก็แสดงรายการ memory files ที่ถูกโหลด ตอนนี้ mod ของ Claude Code สามารถวาด pane ของตัวเองได้แล้ว ดังนั้นมุมมอง effective-instructions จึงเป็นสิ่งที่ใครก็สามารถสร้างขึ้นมาได้ที่นั่น Claude Tag ติดป้ายกำกับ connector และ repository แต่ละตัวด้วย scope ที่มันสืบทอดมา แต่สำหรับ instructions เอกสารกลับแนะนำให้ "ask Claude to repeat its admin instructions" ไม่มี interface ไหนเลยที่แสดงว่าสำหรับคำตอบหนึ่งๆ คำสั่งใดมาจากเลเยอร์ใด เมื่อไม่มีที่มาที่ไป ก็ไม่มี audit trail และเมื่อไม่มี audit trail ก็ไม่มีระบบควบคุมคุณภาพ

ผู้คนกำลังเรียกร้องหาชิ้นส่วนของสิ่งนี้ ประเด็นที่เปิดค้างอยู่ใน public issue tracker ของ Anthropic (github.com/anthropics/claude-code) ตรวจสอบเมื่อวันที่ 2026-10-01:

ประเด็นที่เจ็ด #47741 เรียกร้องให้มี CLAUDE.md ที่จัดการโดยองค์กร และถูกปิดไปเพราะ Claude Code มีสิ่งนี้อยู่แล้ว นี่แหละคือประเด็นสำคัญ: เลเยอร์เหล่านี้มีอยู่แล้วใน Code และใน Slack แต่ประเด็นที่ถูกเรียกร้องนั้นต้องการให้มันอยู่ในที่ที่มีโปรเจกต์อยู่ต่างหาก

3. ต้นทุนคืออะไร และสิ่งที่ token ซ่อนไว้

3.1 Token ไม่ใช่อุปสรรค

การมีเลเยอร์มากขึ้นอาจหมายถึง context ที่มากขึ้นในทุกข้อความ และ AI คิดค่าใช้จ่ายตาม token คำอธิบายนี้ถูกต้องเพียงบางส่วน บนแผน Enterprise ที่คิดค่าใช้จ่ายตามการใช้งาน การใช้จะถูกคิดราคาตามอัตรา API ดังนั้น context ที่มากขึ้นหมายถึงรายได้ที่มากขึ้น ไม่ใช่ลดลง บนแผน Team ค่าที่นั่งจะคงที่เว้นแต่จะเปิดใช้งาน extra usage และ token ส่วนเกินจะแสดงออกมาในรูปแบบของสมาชิกที่แตะขีดจำกัดรายสัปดาห์เร็วขึ้น และ Claude Code ซึ่งคิดค่าใช้จ่ายด้วย token ชุดเดียวกัน ก็มีระบบ cascade สี่ระดับส่งมอบมาให้แล้ว ถ้า token เป็นอุปสรรคจริง มันก็คงไม่มีอยู่ จากการวัดผลในส่วน 3.2 system prompt และ tools ของ Claude Code เองใช้ไปประมาณ 30,200 tokens ก่อนที่จะรวมคำสั่งใดๆ ของเราเข้าไป คำสั่งเต็มรูปแบบของโปรเจกต์เพิ่มเข้ามาอีก 3.5–5.2% จากจำนวนนั้น

3.2 ตัวอย่างการคำนวณ

แท็กบนรูปภาพทุกรูป: REAL = วัดผลจริง หรือตรวจสอบเทียบกับเอกสารของ Anthropic ระหว่างวันที่ 29 กันยายน ถึง 1 ตุลาคม 2026; EST = จำลองขึ้น; IND = เพื่อประกอบการอธิบาย

วัดผลจริงก่อน ผมรันคำถามเดิมใน Claude Code (claude -p, Claude Sonnet 5.5) กับ demo project หนึ่งโปรเจกต์ เงื่อนไขละห้าครั้ง และนำ input tokens ที่ Claude Code รายงานมาใช้ รันบน Claude Code 2.1.286 เมื่อวันที่ 30 กันยายน และอีกครั้งบน 2.1.287 เมื่อวันที่ 1 ตุลาคม จำนวนคำสั่งที่ได้เหมือนกันทุกประการ เมื่อหักการรันที่ไม่มีคำสั่งโปรเจกต์เลยออกไป จะได้ต้นทุนของแต่ละรูปแบบการจัดวาง:

มีสองอย่างที่การจำลองด้านล่างไม่สามารถแสดงได้ ระบบ cascade ใช้ token มากกว่าไฟล์ที่ compile แล้ว 224 tokens สำหรับกฎชุดเดียวกัน: ทุกไฟล์ที่เพิ่มเข้ามามี overhead ในที่นี้คือ marker และ heading ของแอปเองในไฟล์ของแต่ละระดับ รวมกับ framing ของ Claude Code รอบๆ ไฟล์แต่ละไฟล์ที่มันโหลด ยิ่งมีระดับมาก overhead ก็ยิ่งมาก และ Claude Code โหลดจริงมากกว่าที่ public tokenizer ประมาณการไว้ถึง 21–26% แม้จะคูณ 1.30 แล้วก็ตาม ช่องว่างส่วนหนึ่งเกิดจาก overhead ต่อไฟล์แบบเดียวกันนี้ อัตราส่วนยังคงอยู่รอด แต่ตัวเลขดอลลาร์แบบสัมบูรณ์นั้นอยู่ไม่ได้ ดังนั้นให้อ่านตัวเลขดอลลาร์จากการจำลองว่าเป็นค่าที่ต่ำกว่าความเป็นจริง

จากนั้นจำลองในระดับบริษัท ผมจำลอง instruction tokens หนึ่งเดือนของบริษัทตัวอย่าง: พนักงาน 40 คนใน 3 สายงาน, 250 โปรเจกต์ที่กำลังดำเนินการ, รายงาน 6 ประเภทต่อสายงาน, 35 ข้อความต่อคนต่อวันทำงานในเซสชันละ 5 ข้อความ รวมทั้งหมด 29,400 ข้อความ ขนาด token นับจากข้อความคำสั่งตัวอย่างด้วย legacy tokenizer สาธารณะของ Anthropic (ซึ่ง Anthropic เองเรียกว่า "a very rough approximation" สำหรับ Claude 3 ขึ้นไป) และปรับสเกลด้วย 1.30 สำหรับ tokenizer ของ Claude 4.7+ บล็อกองค์กรถูก extrapolate จากตัวอย่าง 597 ตัวอักษรขึ้นไปจนถึงเพดาน 3,000 ตัวอักษร และคู่มือสายงานคือตัวอย่าง 953 ตัวอักษรคูณสาม ราคาเป็นราคาตามรายการของ Claude Sonnet 5.5 (input $2, cache write 5 นาที $2.50, cache read $0.20 ต่อล้าน token) prompt cache มีอายุห้านาทีและรีเฟรชทุกครั้งที่มีการเรียกใช้

• Flat (วิธีแก้ปัญหาเฉพาะหน้าในปัจจุบัน): บล็อกองค์กร ตามด้วยสำเนาคู่มือสายงานของโปรเจกต์นั้นๆ เทมเพลตรายงานทั้งหกแบบ และรายละเอียดเฉพาะของโปรเจกต์

• Tree: องค์กร, สายงาน, เฉพาะเทมเพลตรายงานที่กำลังใช้งาน, แล้วตามด้วยรายละเอียดเฉพาะของโปรเจกต์ โดย compile ส่วนที่แชร์ร่วมกันมากที่สุดไว้ก่อน

ขนาดที่อยู่เบื้องหลังตาราง: บล็อกองค์กร 830 tokens (3,000 ตัวอักษร), คู่มือสายงาน 729, เทมเพลตรายงานหนึ่งแบบ 147, รายละเอียดเฉพาะของโปรเจกต์ 98 (ปัดเศษแล้ว; ยอดรวมคำนวณก่อนการปัดเศษ) การจำลองนี้ไม่นับ system prompt ของ Claude เอง ซึ่งอยู่ก่อนบล็อกองค์กร

ข้อควรระวังตามความจริงสองประการ ประการแรก โครงสร้างต้นไม้ไม่ได้ช่วยประหยัด token ด้วยตัวมันเอง ตัวเลข −29% มาจาก typed tasks: โหลดเฉพาะเทมเพลตของรายงานที่กำลังเขียน ไม่ใช่ทั้งหกแบบ ตัวเลข −62% ส่วนใหญ่มาจากการ compile เลเยอร์ที่แชร์ร่วมกันมากที่สุดไว้ก่อน ทำให้โปรเจกต์หลายร้อยโปรเจกต์แชร์ prefix ที่มี byte ตรงกันทุกประการ: แค่การเรียงลำดับอย่างเดียว โดยที่ยังโหลดเทมเพลตทั้งหกแบบอยู่ ก็ลดต้นทุน shared-cache จาก $36 เหลือ $18 (−51%) แล้ว และ typed tasks ช่วยเติมส่วนที่เหลือ การประหยัดแบบที่สองนี้จะเกิดขึ้นได้ก็ต่อเมื่อ cache ถูกแชร์ข้ามผู้ใช้ บน Claude API cache จะแยกโดดเดี่ยวระหว่างองค์กร และภายในองค์กรหนึ่งๆ จะแยกตาม workspace ดังนั้น prefix ที่เหมือนกันจึงถูกนำกลับมาใช้ข้าม request ภายใน workspace เดียวกันได้ แต่สำหรับ claude.ai เรื่องนี้ไม่ได้ระบุไว้ในเอกสาร มันไม่เกิดขึ้นใน Claude Code เวอร์ชันที่ปล่อยออกมา: ที่นั่น "the cache is effectively scoped to one machine and directory" ดังนั้นคนสองคนที่อยู่ในโฟลเดอร์โปรเจกต์สองโฟลเดอร์จึงใช้ cache ข้ามกันไม่ได้ ให้อ่านคอลัมน์สุดท้ายว่าเป็นสิ่งที่เลเยอร์ native ในแชทสามารถทำได้ ไม่ใช่สิ่งที่มีให้ใช้ในวันนี้ ข้อโต้แย้งที่สมเหตุสมผล: Skills โหลดแบบ on demand อยู่แล้ว ดังนั้น workspace แบบ flat ที่ย้ายเทมเพลตเข้าไปใน Skills ก็ได้รับประโยชน์จาก −29% บางส่วนแล้วในวันนี้ สิ่งที่ Skills ขาดไปในแชทและ Cowork คือ scope และการสืบทอด: skill ไม่สามารถเป็นของสายงานหนึ่งแล้วไหลลงไปยังโปรเจกต์ของสายงานนั้นได้ (ใน Claude Code skill ในโฟลเดอร์ย่อยจะโหลดสำหรับเซสชันที่เริ่มในหรือต่ำกว่าโฟลเดอร์นั้น) ประการที่สอง ตัวเลขเหล่านี้เป็นเพียง instruction token และในระดับนี้จะมีค่าใช้จ่ายตั้งแต่ $14 ถึง $149 ต่อเดือน ขึ้นอยู่กับการ caching ประวัติการสนทนาและ output ครองสัดส่วนหลักในบิลจริง ข้อโต้แย้งที่หนักแน่นสำหรับโครงสร้างต้นไม้คือความถูกต้องแม่นยำ และบนแผน Team คือขีดความสามารถ ไม่ใช่ใบแจ้งหนี้

การวัดผลด้านบนจำลองผลกระทบของ typed-task บนโครงสร้างต้นไม้จริงใน Claude Code แทนที่จะใช้ขนาดที่ตั้งสมมติฐาน: −20% สำหรับแบบ cascade และ −34% สำหรับแบบ compiled เมื่อเทียบกับ −29% ของการจำลอง สายงานที่มี task ประเภทเดียวจะไม่ประหยัดอะไรได้เลยจาก typed tasks

3.3 คำตอบเดียวกัน จาก Claude ตัวจริง

ผมถามคำถามเดิมกับ Claude Code สี่สิบครั้ง: สิบคำตอบอิสระภายใต้เงื่อนไขสี่แบบ แบ่งเป็นสองล็อต ล็อตละห้าครั้ง ห่างกันหนึ่งวัน คำถามคือผลการทดสอบความหนาแน่นภาคสนามของชั้นดินรองพื้นทางผ่านหรือไม่ ที่ค่า 112.3 pcf เทียบกับ maximum dry density 115.8 pcf โดยกำหนดไว้ที่ 98% คำสั่งที่ให้ไปคือกฎหกข้อของบริษัท หรือ prompt บรรทัดเดียวแบบ "helpful assistant" และภาษาที่ใช้คือภาษาอังกฤษหรือสเปน คำตอบทั้งสี่สิบครั้งให้ข้อสรุปเดียวกัน: 97.0%, ไม่ผ่าน

Claude Code รายงานตัวเลข output สองตัว: token ที่ถูกคิดค่าใช้จ่าย และจำนวน token ในนั้นที่เป็น thinking ซึ่งผู้อ่านไม่มีวันได้เห็น

ข้อค้นพบสี่ประการ:

• กฎของบริษัททำให้คำตอบยาวขึ้น 1.4 เท่าบนหน้าจอ และยาวขึ้น 1.8–1.9 เท่าในใบแจ้งหนี้ ส่วนที่เพิ่มขึ้นซึ่งมองเห็นได้คือหัวข้อ flags, standards และ limitations ที่กฎร้องขอ ในระบบควบคุมคุณภาพ ส่วนเหล่านี้คือส่วนที่มีคุณค่า

• ภายใต้กฎของบริษัท มากกว่าหนึ่งในสามของ output ที่ถูกคิดค่าใช้จ่ายนั้นมองไม่เห็น 37% ของ output token ที่ถูกคิดค่าใช้จ่ายคือ thinking เทียบกับ 16% ภายใต้ prompt ธรรมดา ในภาษาอังกฤษ ผู้อ่านเห็น 447 tokens แต่จ่ายสำหรับ 711 tokens

• ภาษาสเปนใช้ visible tokens เป็น 1.2 เท่าของภาษาอังกฤษ สำหรับคำตอบที่มีความยาวเป็นคำต่างกันไม่เกิน 4% เมื่อวัดด้วยวิธีเดียวกัน กฎของบริษัทใช้ input tokens เป็น 1.53 เท่าเมื่อเขียนเป็นภาษาสเปน

• ข้อสรุปเดียวกันถูกคิดค่าใช้จ่ายตั้งแต่ 317 ถึง 953 tokens คำตอบที่ยาวที่สุดเสียค่าใช้จ่ายเป็นสามเท่าของคำตอบที่สั้นที่สุด การคิดค่าใช้จ่ายตาม token ไม่สามารถแยกแยะความรัดกุมจากการยัดเยียดเนื้อหาได้ แต่ acceptance criteria ทำได้

อัตราส่วนเหล่านี้ขยับไปมาระหว่างล็อตละห้าครั้ง อัตราส่วนบนหน้าจอสำหรับกฎของบริษัทอยู่ที่ 1.43–1.52 ในล็อตแรก และ 1.27–1.31 ในล็อตที่สอง อัตราส่วนที่ถูกคิดค่าใช้จ่ายอยู่ที่ 1.78–1.82 และต่อมาคือ 1.70–2.05 อัตราส่วนของภาษาสเปนอยู่ที่ 1.29–1.38 และต่อมาคือ 1.14–1.18 ทิศทางไม่เคยเปลี่ยนแปลง ขนาดนี้เชื่อถือได้ในระดับนัยสำคัญหนึ่งหลัก

วิธีการ: Claude Code 2.1.286 เมื่อวันที่ 2026-09-30 และ 2.1.287 เมื่อวันที่ 2026-10-01, claude -p --output-format json, Claude Sonnet 5.5 ทุก tool ถูกห้ามใช้ และไฟล์ ~/.claude ส่วนบุคคลถูกตัดออก ดังนั้นจึงมีเพียงคำสั่งที่ระบุไว้เท่านั้นที่แตกต่างกันระหว่างเงื่อนไข จำนวน token มาจากรายงานการใช้งานของ Claude Code เอง รวมถึง thinking_tokens; ต้นทุนรายเดือนใช้อัตรา $10 ต่อล้าน output token ของ Sonnet 5.5 คูณกับค่าเฉลี่ยที่ถูกคิดค่าใช้จ่าย สคริปต์วัดผล ข้อมูลทั้งสองล็อต ตัวเลขที่รวมเข้าด้วยกัน และคำตอบทั้งหมดถูกเก็บไว้โดยผู้เขียนและสามารถขอดูได้ บทความเวอร์ชันแรกประเมินตัวเลขเหล่านี้ด้วย subagents และ public tokenizer การประเมินเหล่านั้นถูกแทนที่แล้ว

3.4 เมื่อกฎขัดแย้งกัน ถ้อยคำคือผู้ตัดสิน

เอกสารของ Anthropic ยอมรับว่าคำสั่งที่ขัดแย้งกันอาจถูกแก้ไข "arbitrarily" ผมทดสอบความขัดแย้งหนึ่งกรณีที่เลเยอร์สายงานที่ขาดหายไปจะก่อขึ้น กฎองค์กรบอกว่าให้ใช้หน่วยวัดแบบ U.S. customary; กฎโปรเจกต์บอกว่าให้รายงานความหนาแน่นในระบบ SI ผมวางมันไว้ในตำแหน่งที่โครงสร้างต้นไม้จะทำ: กฎองค์กรในไฟล์ CLAUDE.md ที่ storage root, กฎโปรเจกต์ในไฟล์ CLAUDE.md ในโฟลเดอร์โปรเจกต์ ทั้งคู่โหลดโดย cascade ของ Claude Code เอง จากนั้นผมรันการตั้งค่าเดิมโดยทำเครื่องหมายกฎองค์กรว่ามีผลบังคับ ด้วยถ้อยคำเท่านั้น: แท็ก ENFORCED ใน label และประโยคที่เพิ่มเข้ามาอีกหนึ่งประโยคว่า "This rule is enforced: no line or project rule may override it." การตั้งค่าแต่ละแบบรันสิบครั้งในวันที่ 30 กันยายน และอีกสิบครั้งในวันที่ 1 ตุลาคม

มันไม่ได้สุ่มเลือก เมื่อไม่มีอะไรถูกประกาศไว้ Claude เลือกกฎที่ใกล้กว่าและเจาะจงกว่าทุกครั้ง สิบสี่จากยี่สิบคำตอบบอกเหตุผลด้วย ("that rule is more specific than the firm-wide U.S. customary rule" หรือว่ามัน override กฎของบริษัท) ห้าคำตอบอ้างถึงแค่กฎโปรเจกต์และไม่เคยพูดถึงเลยว่ากฎของบริษัทขัดแย้งกัน เมื่อประกาศผลบังคับด้วยถ้อยคำ กฎองค์กรชนะทุกครั้ง และทุกคำตอบระบุว่ากฎบริษัทที่ถูกบังคับใช้นั้นมีความสำคัญกว่า ล็อตที่สองทำซ้ำหน่วยวัดได้ถูกต้อง 10 จาก 10 ครั้งในทุกเงื่อนไข และความแตกต่างระหว่างสองแถวนี้อยู่นอกเหนือโอกาสที่จะเกิดขึ้นโดยบังเอิญไปไกล (Fisher's exact test, p < 0.0001) ส่วนคำอธิบายนั้นไม่ค่อยคงเส้นคงวาเท่า: เก้าในสิบคำตอบบอกเหตุผลที่กฎโปรเจกต์ชนะในล็อตแรก แต่เหลือเพียงห้าในสิบในล็อตที่สอง

นั่นเป็นข่าวดีสำหรับโมเดล แต่เป็นข่าวร้ายสำหรับพื้นที่ทำงาน ลำดับความสำคัญนั้นมีอยู่จริง แต่มันแฝงอยู่ในถ้อยคำของกฎ ซึ่งใครก็ตามที่แก้ไขเลเยอร์ไหนก็สามารถเปลี่ยนได้ และไม่มีใครตรวจสอบมันในฐานะการตัดสินใจเรื่องลำดับความสำคัญเลย และเมื่อกฎระดับล่างชนะ หนึ่งในสี่ของคำตอบก็ไม่ได้บอกผู้อ่านว่ามีกฎระดับสูงกว่าถูกข้ามไป การทดลองนำร่องในบทความเวอร์ชันแรก ซึ่งใส่กฎทั้งสองไว้ในพรอมต์เดียวแทนที่จะใช้ระบบ cascade ก็ให้ผลลัพธ์ที่เปลี่ยนไปเมื่อสลับลำดับเท่านั้น (กฎองค์กรขึ้นก่อน: SI 5 จาก 5; กฎองค์กรอยู่ท้ายสุด: SI 2 จาก 5 และอีก 3 จาก 5 ให้หน่วยมาทั้งสองแบบหรือถามกลับว่าควรใช้แบบไหน)

ไม่ควรขอให้โมเดลใด ๆ มาตัดสินความขัดแย้งที่องค์กรน่าจะจับได้ตั้งแต่ตอนเขียนกฎ Claude Code มีคำตอบให้บางส่วน คำสั่ง /doctor prompt-audit จะขอให้ Claude ค้นหาไฟล์คำสั่งที่ขัดแย้งกันเอง เมื่อมีผู้ใช้เรียกใช้งาน และตั้งแต่วันที่ 1 ตุลาคม mod สามารถบังคับลำดับการทำงานในโค้ดได้แล้ว: mod ขององค์กรจะทำงานก่อน mod ของบุคคล และเมื่อ guard ที่มากับระบบเริ่มทำงาน กฎ deny จะชนะ mod ของบุคคล แต่ทั้งสองอย่างนี้ไม่ครอบคลุมถึงข้อความคำสั่ง ไฟล์คำสั่งยังคงถูกนำมาต่อกัน และเอกสารอธิบายผลลัพธ์ไว้สามแบบ: Claude “อาจเลือกอย่างใดอย่างหนึ่งตามอำเภอใจ”; เมื่อกฎของผู้ใช้และกฎของโปรเจกต์ขัดแย้งกัน “Claude อาจทำตามอย่างใดอย่างหนึ่ง”; และ “เมื่อคำสั่งขัดแย้งกัน Claude จะใช้ดุลยพินิจในการปรับให้เข้ากัน” ผลลัพธ์ที่ยี่สิบจากยี่สิบครั้งคือหน้าตาของดุลยพินิจนั้นในกรณีนี้ Claude Tag ประกาศลำดับการทำงานสำหรับ scope ทั้งสามของตัวเอง และเรียกผลลัพธ์นั้นว่า “แนวทาง ไม่ใช่ guardrail ที่บังคับใช้” ส่วนการตรวจสอบใน reference implementation จะปฏิเสธการเปลี่ยนแปลงแบบนี้ “R-22 sets units.density=SI; R-01 (org:firm) enforces US” ก่อนที่อะไรจะไปถึง Claude เสียอีก และคำว่า enforced เป็นฟิลด์หนึ่งในกฎ ไม่ใช่แค่ประโยคที่เขียนไว้ในกฎ

ความหนาแน่นของคำสั่งทำให้สถานการณ์แย่ลงไปอีก ในเบนช์มาร์ก IFScale (2025) ความแม่นยำของ Claude Sonnet 4 ลดลงจาก 100% ที่ 10 คำสั่งพร้อมกัน เหลือเพียง 42.9% ที่ 500 คำสั่ง

3.5 หน่วยวัดแบบ compute หรือพลังงานจะยุติธรรมกว่าไหม?

Token เป็นตัวแทนของ compute ที่สมเหตุสมผล ภายในโมเดลเดียวกัน: ยิ่งมี token มาก ฮาร์ดแวร์ก็ยิ่งต้องทำงานหนักขึ้นจริง นั่นจึงเป็นเหตุผลที่ว่าราคาแบบอิง compute หรือพลังงานจะ ไม่ ช่วยแก้ปัญหา language penalty ภาษาสเปนมีต้นทุนสูงกว่าเพราะ tokenizer บีบอัดได้น้อยกว่า และ token ส่วนเกินเหล่านั้นคือ compute จริง ๆ วิธีแก้ปัญหาคือการใช้ tokenizer ที่ดีขึ้น หรือการวัดการใช้งานที่ normalize ตามเนื้อหา

หน่วย compute แบบ normalized จะยังมีประโยชน์ในสามด้าน มันทำให้เปรียบเทียบโมเดลและผู้ให้บริการต่างกันได้ มันเป็นค่าทางกายภาพที่รายงานได้ เช่น สำหรับการรายงานด้านความยั่งยืน และถ้าสัมประสิทธิ์ถูกกำหนดตายตัวเทียบกับฮาร์ดแวร์อ้างอิง ผู้ให้บริการก็จะเก็บผลประโยชน์จากประสิทธิภาพที่ตัวเองพัฒนาไว้ได้ ซึ่งเป็นแรงจูงใจที่ถูกต้อง เรามีตัวอย่างให้เห็นแล้ว: ผู้ให้บริการคลาวด์เคยขายหน่วยแบบ normalized อย่าง EC2 Compute Unit

แต่มันก็มีปัญหาจริงจัง ลูกค้าไม่สามารถตรวจสอบได้หากไม่มีมาตรฐานและผู้ตรวจสอบ พลังงานที่ใช้จริงขึ้นอยู่กับฮาร์ดแวร์ ประสิทธิภาพของดาต้าเซ็นเตอร์ การจัด batch และระบบสายส่งไฟฟ้า และ Anthropic ก็ไม่ได้เปิดเผยข้อมูลพลังงานต่อ request ผมพบแต่ตัวเลขประมาณการจากบุคคลที่สามเท่านั้น ที่สำคัญที่สุด compute ก็ยังเป็นแค่ input มันไม่ได้บอกว่าคำตอบนั้นถูกต้องหรือไม่

ข้อสรุปของผมคือการแยกออกเป็นสามเลเยอร์:

1. เรียกเก็บเงิน เป็น token หรือหน่วย compute แบบ normalized

1. เปิดเผย ข้อมูลพลังงานต่องานและต่อ node

1. บริหารจัดการ ด้วยต้นทุนต่อผลลัพธ์ที่ผ่านการตรวจสอบ

สำหรับแผน Team ขั้นต่ำที่สุดที่ต้องทำคือเผยแพร่ขีดจำกัดรายสัปดาห์ในหน่วยที่ระบุชัดเจน สิทธิ์การใช้งานต่อเซสชันถูกระบุว่าเป็น “1.25 เท่าของโควตาการใช้งานต่อเซสชันของแผน Pro” ส่วนขีดจำกัดรายสัปดาห์นั้นไม่มีตัวเลขประกาศออกมาเลย จึงไม่สามารถวางแผนงบประมาณกับสิ่งใดได้เลย

ดังที่ FinOps Foundation กล่าวไว้ว่า “token คือหน่วยสำหรับการเรียกเก็บเงิน ไม่ใช่หน่วยของคุณค่า” โครงสร้างลำดับชั้นคือสิ่งที่ทำให้เรานิยามคุณค่าได้ เพราะเป็นที่ที่เกณฑ์การยอมรับ (acceptance criteria) จะอยู่ได้

3.6 เหตุผลที่เป็นไปได้มากกว่าว่าทำไมมันถึงยังไม่ถูกสร้างขึ้นมา

1. ลำดับความสำคัญโดยนัย เอกสารของ Anthropic เองก็ยอมรับว่าคำสั่งที่ขัดแย้งกันโดยตรงอาจทำให้เกิดพฤติกรรมที่แตกต่างกัน และหัวข้อ 3.4 แสดงให้เห็นว่าลำดับความสำคัญเป็นไปตามถ้อยคำของกฎนั้น ๆ การซ้อนเลเยอร์ทำให้ความขัดแย้งทวีคูณ และการทำตามคำสั่งจะแย่ลงเมื่อความหนาแน่นเพิ่มขึ้น: ในเบนช์มาร์ก IFScale (2025) แม้แต่โมเดลที่ดีที่สุดที่ทดสอบก็ยังทำได้แค่ความแม่นยำ 68% ที่ 500 คำสั่ง keyword พร้อมกัน (เบนช์มาร์กที่อ้างถึงในหัวข้อ 3.4)

1. การสืบทอดสิทธิ์ ถ้าความรู้สืบทอดลงมาตามโครงสร้างต้นไม้ สิทธิ์การเข้าถึงก็ต้องสืบทอดตามไปด้วย นั่นหมายถึงการสร้าง permission model ใหม่ภายใต้ทุกเลเยอร์

1. ความชอบที่จะใช้ memory และ retrieval มากกว่าเลเยอร์แบบตายตัว

1. ความเรียบง่ายที่เน้นผู้บริโภคเป็นหลัก เครื่องมือสำหรับโค้ดได้โครงสร้างต้นไม้มาจาก file system ฟรี ๆ แต่ผลิตภัณฑ์แชทต้องสร้างขึ้นใหม่เอง

Anthropic ยังไม่เคยบอกต่อสาธารณะว่าทำไมแชทของ Claude และ Cowork ถึงไม่มีโครงสร้างลำดับชั้น ทุกอย่างในส่วนนี้เป็นการอนุมานจากสิ่งที่ปล่อยออกมาใช้งานจริง

4. โมเดลอ้างอิง

การออกแบบนี้ยืมแนวคิดมาจากระบบที่แก้ปัญหานี้ไปแล้ว: โครงสร้างลำดับชั้นทรัพยากรคลาวด์ (AWS Organizations, Google Cloud Org Policy, Azure management groups), directory policy (Active Directory Group Policy) และระบบ cascade ของ CLAUDE.md ใน Claude Code เอง ความสัมพันธ์ระหว่าง node ใช้คำเพียงห้าคำ: contains, inherits, uses, sealed และ shared

4.1 Mount โครงสร้างต้นไม้ที่องค์กรมีอยู่แล้ว

อย่าบังคับให้คนต้องสร้างองค์กรของตัวเองขึ้นมาใหม่ในพื้นที่ทำงาน AI เพราะ file server หรือระบบเอกสารก็คือแหล่งข้อมูลหลัก (source of truth) อยู่แล้ว เลือกใช้เส้นทางเดียว:

หมายเลขงาน 26GT301 เข้ารหัสโครงสร้างต้นไม้อยู่แล้ว: ปี สายงาน ลำดับ พื้นที่ทำงานควร mount โครงสร้างนี้ ไม่ใช่คัดลอกมันมา

4.2 Node ที่มีกฎ, node สำหรับจัดกลุ่ม, โปรเจกต์ และงาน

• Node ที่มีกฎ: องค์กร, สายงาน, โปรเจกต์, งาน แต่ละตัวจะมีสามสิ่งเหมือนกัน: context (คำสั่งและความรู้), policy (เครื่องมือ ข้อมูล และ connector ใดที่ได้รับอนุญาต) และ identities (บัญชี connector ที่ผูกไว้กับมัน)

• Node สำหรับจัดกลุ่ม: ซีรีส์, ปี, ภูมิภาค พวกมัน ไม่มีกฎใด ๆ มีไว้เพื่อการนำทาง การเก็บรักษาข้อมูล และวงจรชีวิต การแยกพวกนี้ออกมาช่วยให้ต้นไม้ของกฎตื้น เพียงสามถึงสี่ระดับ ตามที่คำแนะนำของ Microsoft สำหรับ management groups แนะนำไว้ (“ไม่เกินสามถึงสี่ระดับ”)

• โปรเจกต์คือ container ที่มี key มันจะถูกสร้างขึ้นอัตโนมัติ: เมื่อมีโฟลเดอร์ที่ตรงกับรูปแบบ key ของสายงานปรากฏขึ้น (เช่น {YY}GT{NNN}_{Name} ภายใต้ root ของสายงาน) node โปรเจกต์จะถูกสร้างขึ้น สืบทอดจากสายงานของมัน และได้รับสิทธิ์เข้าถึง connector เฉพาะในโฟลเดอร์นั้น มันจะเก็บเฉพาะสิ่งที่แตกต่างจากสายงาน: สมาชิก, ลูกค้า, ข้อกำหนด และจะเปลี่ยนสถานะจาก open ไป closed แล้วไป archived (แผนภาพที่ 2)

• งานมีการระบุประเภท ประเภทของมันมาจากแค็ตตาล็อกของสายงาน (รายงานความหนาแน่น, บันทึกการเจาะสำรวจ) ประเภทนั้นจะมี template และ acceptance criteria ติดมาด้วย ผลลัพธ์จะถูกจัดเก็บกลับเข้าไปในโฟลเดอร์โปรเจกต์ตามธรรมเนียมการตั้งชื่อของบริษัท และมีผู้ตรวจสอบเป็นผู้ยอมรับ Skills เป็นสิ่งที่ใกล้เคียงกับประเภทงานมากที่สุดที่ Claude มีในปัจจุบัน บนแผน Enterprise สามารถแชร์ skills กับกลุ่มได้ แต่นั่นคือการแจกจ่าย ไม่ใช่การสืบทอด: ไม่มีอะไรไหลลงไปตามกิ่งก้าน

การทำซ้ำ (recursion) นี้ตั้งใจให้เป็นเช่นนั้น Viable System Model ของ Stafford Beer ระบุไว้อย่างตรงไปตรงมาว่า: “ในโครงสร้างองค์กรแบบ recursive ระบบที่ใช้งานได้จริงทุกระบบจะบรรจุระบบที่ใช้งานได้จริงอีกระบบหนึ่งไว้ และถูกบรรจุอยู่ในระบบนั้นด้วย”

4.3 Parent หลักหนึ่งตัว บวกกับ overlay

Christopher Alexander โต้แย้งในปี 1965 ว่า “เมืองไม่ใช่ต้นไม้” โครงสร้างในโลกความจริงทับซ้อนกัน ลูกค้า ข้อกำหนดของหน่วยงาน หรือประเภทงาน สามารถครอบคลุมหลายสายงานได้ ดังนั้นทุก node จึงมี parent หลักหนึ่งตัว และชุดกฎที่ตัดข้ามสายงานจะถูกแนบเข้ามาเป็น overlay (uses) ความขัดแย้งจะถูกจัดการด้วยวิธีเดิมทุกครั้ง: deny ชนะเสมอ นอกเหนือจากนั้น node ที่อยู่ใกล้ที่สุดจะเป็นผู้ชนะ

4.4 สองช่องทาง สองความหมาย

นี่คือหัวใจของการออกแบบ และเป็นจุดที่โครงสร้างลำดับชั้นส่วนใหญ่พลาด

• Context จะถูกนำมาต่อกัน คำสั่งและความรู้จะถูกรวมเข้าด้วยกันตั้งแต่ root ลงมา เหมือนที่ CLAUDE.md ทำ

• Policy ใช้หลักการ deny-by-default เครื่องมือหรือ connector จะได้รับอนุญาตก็ต่อเมื่อมี allow อยู่ตลอดเส้นทางจาก root เท่านั้น และการ deny อย่างชัดเจนที่จุดใดจุดหนึ่งด้านบนจะชนะเสมอ เหมือนที่ AWS Service Control Policies ทำ parent สามารถ标记กฎเป็น enforced ได้ และ child จะไม่สามารถบล็อกมันได้ เหมือนใน Group Policy

การเอาสองอย่างนี้มารวมกันคือความผิดพลาดคลาสสิก context ที่เป็นคำแนะนำควรถูกผสมผสานกันได้ แต่การบังคับใช้นั้นไม่ควร

4.5 Compile ก่อนที่โมเดลจะอ่านมัน

ทุกวันนี้ คำสั่งที่ขัดแย้งกันจะถูกจัดการโดยโมเดลในตอนตอบคำถาม ทางแก้คือ effective-instructions compiler ที่จะทำงานก่อนที่โมเดลจะเห็นอะไรเลย:

1. รวม context ตั้งแต่ root ถึง leaf

1. ใช้ policy: deny ชนะ และ allow ต้องมีอยู่ตลอดทั้งเส้นทาง

1. ปฏิบัติตามกฎแบบ enforced จาก parent

1. ประทับ ID และเลเยอร์ให้กับทุกกฎ

1. จัดเรียงบล็อกตามระดับการแชร์ของแต่ละส่วน และกำหนด token budget ต่อเลเยอร์

ความขัดแย้งจะไม่มาถึงขั้นตอนนี้เลย: มันจะถูกปฏิเสธไปก่อนแล้วตั้งแต่ตอนเขียนกฎ และการอนุมัติต้องมาจากคนอื่นที่ไม่ใช่ผู้เขียน (แผนภาพที่ 3 เลนด้านล่าง)

เนื่องจากความขัดแย้งถูกจัดการตอน compile ผลลัพธ์จึงสามารถจัดเรียงตามระดับการแชร์ของแต่ละส่วนได้ ไม่จำเป็นต้องเรียงตามความลึกอย่างเดียว: องค์กร, สายงาน, template ของประเภทงาน, แล้วจึงเป็นรายละเอียดของโปรเจกต์ ลำดับนี้จะช่วยเพิ่ม cache hit ให้สูงสุด (หัวข้อ 3.2) มันสอดคล้องกับ cache breakpoint สี่จุดของ Anthropic พร้อม token budget ต่อเลเยอร์ แม้ในทางปฏิบัติอาจต้องใช้ breakpoint หนึ่งจุดสำหรับการสนทนาเองก็ตาม

4.6 Identity ผูกกับกิ่งก้าน ไม่ใช่กับบุคคล

Identity ของ connector (บัญชี, tenant, scope) จะผูกกับ node ไม่ใช่กับบุคคล Claude Tag ทำงานแบบนี้กับ Slack channel อยู่แล้ว: แอดมินจะผูก service account เข้ากับ scope และ credential ของ scope ที่แคบที่สุดจะเป็นผู้ชนะ โมเดลในที่นี้ขอสิ่งเดียวกันในระดับที่ลึกขึ้นอีกหนึ่งขั้น คือในสายงานและโปรเจกต์ของมัน บุคคลที่ทำงานในสององค์กรจะมีต้นไม้แบบ sealed สองต้น พวกเขาจะสลับต้นไม้ ไม่ใช่สลับบัญชี ไม่มีอะไรข้ามไปมาระหว่างต้นได้ เว้นแต่เจ้าของทั้งสองจะแชร์กันอย่างชัดเจน primitive ทางเทคนิคนี้มีอยู่แล้ว: ข้อกำหนดการให้สิทธิ์ของ MCP ใช้ OAuth token ที่ผูกกับ audience (RFC 8707 resource indicators, RFC 9728 protected resource metadata) และกำหนดว่าเซิร์ฟเวอร์ “ต้องไม่ยอมรับหรือส่งต่อ token อื่นใด” (specification version 2026-07-28)

4.7 สิทธิ์ปฏิบัติตามโครงสร้างต้นไม้

Principals: บุคคล, กลุ่ม, service accounts, ผู้ใช้ภายนอก (เช่น ลูกค้า) และตัว agent เอง

Agent จะไม่มีสิทธิ์เกินกว่าบุคคลหรือ node เด็ดขาด Claude จะทำงานด้วยสิทธิ์ของผู้ใช้ที่เรียกใช้งาน ตัดกับ policy ของ node มันไม่สามารถเปลี่ยนกฎหรือสิทธิ์ได้ ทำได้เพียงเสนอการเปลี่ยนแปลงเท่านั้น (ทุกวันนี้ Claude สามารถอัปเดตคำสั่งโฟลเดอร์ Cowork ได้ด้วยตัวเอง ในโมเดลนี้ สิ่งนั้นจะกลายเป็นข้อเสนอที่ต้องมีคนอนุมัติ)

การประเมินสิทธิ์ การมอบสิทธิ์จะไหลลงล่างเท่านั้น ไม่เคยไหลขึ้นหรือไหลไปด้านข้าง สิทธิ์ที่มีผลจริง ณ node หนึ่งคือสิ่งที่ role บนเส้นทางนั้นมอบให้ ภายในขอบเขตที่ policy อนุญาตตลอดทั้งเส้นทาง หักลบด้วย deny ใด ๆ ที่อยู่ด้านบน overlay จะมอบสิทธิ์เข้าถึงเฉพาะเนื้อหาของตัวเองเท่านั้น: การอ่านข้อกำหนดไม่ได้เปิดสิทธิ์เข้าถึงโปรเจกต์ที่ใช้ข้อกำหนดนั้น

วงจรชีวิต

• Open: role ต่าง ๆ ถูกนำไปใช้ตามที่มอบสิทธิ์ไว้

• Closed: ไม่รับงานใหม่ แต่การตรวจสอบที่ค้างอยู่สามารถทำจนเสร็จได้

• Archived: อ่านได้อย่างเดียวสำหรับทุกคน เฉพาะเจ้าของเท่านั้นที่กู้คืนได้ และการกู้คืนจะถูกบันทึก log ไว้

• Sealed tree: ไม่มีอะไรข้ามผ่านไปได้หากไม่มีการแชร์อย่างชัดเจน

ข้อยกเว้นและการมอบอำนาจ ข้อยกเว้นต้องมีกรอบเวลา มีเหตุผลรองรับ และต้องได้รับการอนุมัติจากผู้อื่นที่ไม่ใช่ผู้ร้องขอ มันจะหมดอายุไปเองและถูกนับจำนวน เพราะการ override ทุกครั้งคือเกาะที่ต้องดูแลรักษาถาวร ข้อจำกัดของ broken-inheritance ใน SharePoint คืออุทาหรณ์สอนใจ การมอบอำนาจจะไม่สามารถให้สิทธิ์เกินกว่าที่ผู้มอบมีอยู่ได้ สิทธิ์เข้าถึงฉุกเฉิน (break-glass) ของ owner นั้นมีอยู่จริง ถูกบันทึก log เสมอ และจะถูกตรวจสอบภายหลัง

บนแผน Team สิ่งนี้ทำงานได้โดยไม่ต้องมีกลุ่ม: สิทธิ์ถูกผูกไว้ที่ node ดังนั้นองค์กรที่มีแค่สี่ role ก็ยังได้สิทธิ์แบบ per-branch อยู่ดี

4.8 เลเยอร์ต่าง ๆ ทำงานร่วมกันอย่างไร

โครงสร้างต้นไม้จะคุ้มค่าแก่การสร้างก็ต่อเมื่อการเปลี่ยนแปลงเดินทางผ่านมันได้ การโต้ตอบสามรูปแบบนี้แบกรับงานส่วนใหญ่ไว้ (แผนภาพที่ 5):

• Push down หัวหน้าสายงานเผยแพร่กฎเวอร์ชันใหม่ ทุกโปรเจกต์ในสายงานนั้นจะอ่านมันในการ compile ครั้งถัดไป ข้อยกเว้นที่ได้รับการอนุมัติจะใช้เวอร์ชันเก่าต่อไปจนกว่าจะหมดอายุ และ artifact ที่จัดเก็บไปแล้วจะคงเวอร์ชันที่ใช้ตอนสร้างมันไว้

• Pull up สมาชิกปรับปรุง template ภายในโปรเจกต์หนึ่งแล้วเสนอขึ้นไป หัวหน้าสายงาน ไม่ใช่ผู้เสนอ จะเป็นผู้อนุมัติ และโปรเจกต์พี่น้องอื่น ๆ จะสืบทอดมันไป ทุกวันนี้การปรับปรุงนั้นจะติดอยู่ในโปรเจกต์ที่เกิดการเปลี่ยนแปลงเท่านั้น

• Across ข้อกำหนดของหน่วยงานเปลี่ยนเพียงครั้งเดียว โปรเจกต์ในสามสายงานจะ recompile ด้วยข้อกำหนดนั้น โดยที่ตัวสายงานเองไม่ต้องเปลี่ยนอะไร ความขัดแย้งกับกฎของสายงานจะถูกปฏิเสธตั้งแต่ตอนเขียนอัปเดต

Request เดียวแสดงให้เห็นทุกเลเยอร์พร้อมกัน (แผนภาพที่ 6): ต้นไม้ตรวจสอบสิทธิ์ของสมาชิกและสถานะของโปรเจกต์ compiler สร้างบล็อกคำสั่ง Claude อ่านข้อมูลฟิลด์ผ่าน identity ที่ scope ไว้กับโฟลเดอร์ของโปรเจกต์นั้น จัดเก็บ artifact ที่ระบุประเภทกลับลงในโฟลเดอร์ และผู้ตรวจสอบที่ไม่ได้เป็นคนเขียนมันจะเป็นผู้ยอมรับ ทุกขั้นตอนถูกบันทึกลง log และต้นทุนจะถูกคิดเข้ากับ key ของโปรเจกต์

4.9 โครงสร้างข้อมูล

การจัดเตรียม (provisioning) เป็นแบบ event-driven: โฟลเดอร์ใหม่ที่ตรงกับ key_pattern ภายใต้ storage_root ของสายงานจะสร้าง node โปรเจกต์ขึ้นมา answer_log จะให้ข้อมูล provenance สำหรับทุกคำตอบและต้นทุนต่อ node

4.10 วัดที่ผลลัพธ์ ไม่ใช่ token

ประเภทงานแต่ละแบบจะมี acceptance criteria: นิยามของคำว่าเสร็จสมบูรณ์ เมื่อมีสิ่งเหล่านี้ หน่วยวัดงาน AI ที่ดีกว่าก็จะวัดผลได้:

cost per verified outcome = (token cost + review time) ÷ accepted deliverables

เนื่องจากทุกคำตอบถูกบันทึก log เทียบกับ node ต้นทุน AI จึงสามารถคิดเข้ากับ key ของโปรเจกต์ได้เหมือนค่าแรงและวัสดุ บางส่วนของสิ่งนี้มีอยู่แล้ว: Claude Tag รายงานและจำกัดการใช้จ่ายต่อ channel และ telemetry ของ Claude Code สามารถแท็กตามแผนก ศูนย์ต้นทุน หรือ repository ได้ด้วยมือ แต่ไม่มีอะไรผูกกับ key ของโปรเจกต์เลย และไม่มีอะไรหารด้วยจำนวน deliverable ที่ผ่านการยอมรับ สำหรับบริษัทที่เรียกเก็บเงินตามหมายเลขงาน AI จะกลายเป็นต้นทุนงานโดยตรงแทนที่จะเป็นค่าใช้จ่ายทั่วไป (overhead) ในวงการวิศวกรรม คุณจ่ายเงินให้กับ deliverable ที่ผ่านการตรวจสอบและ seal แล้ว ไม่ใช่จ่ายให้ไส้ดินสอ งาน AI ก็ควรวัดผลด้วยวิธีเดียวกัน

4.11 ข้อโต้แย้งและคำตอบ

“Skills และ plugins ก็ทำสิ่งนี้อยู่แล้ว” Skill จะโหลดเมื่อ Claude เห็นว่ามันเกี่ยวข้อง ซึ่งเป็นการดูจากความเกี่ยวข้อง ไม่ใช่การรับประกัน การจัดเตรียม (provisioning) จะมอบ skill ให้ทุกคน บนแผน Enterprise plugin ที่พก skill มาสามารถบังคับใช้กับกลุ่มใดกลุ่มหนึ่งได้ นั่นคือสิ่งที่ใกล้เคียงกับสายงานมากที่สุดในแชทและ Cowork ทุกวันนี้ แต่มันยังขาดไปในสามจุด: ใช้ได้เฉพาะแผน Enterprise, มุ่งเป้าไปที่บุคคลไม่ใช่โปรเจกต์, และไม่มีอะไรไหลลงจากสายงานไปยังโปรเจกต์ กฎที่ต้องบังคับใช้เสมอในสายงานหนึ่งจะพึ่งพาการตรวจจับความเกี่ยวข้องไม่ได้

“Mods ก็ทำสิ่งนี้อยู่แล้ว” ใน Claude Code ทำได้บางส่วน ตั้งแต่วันที่ 1 ตุลาคม 2026 mod สามารถเขียน system prompt ใหม่ ปฏิเสธการเรียกใช้ tool และวาด panel ได้ และ mod ขององค์กรจะทำงานก่อน mod ของบุคคล ดังนั้น compiler, การตรวจสอบตอนเขียน และมุมมอง effective-instructions ในบทความนี้จึงสามารถสร้างเป็น mod ได้ในวันนี้ และหัวข้อ 6 ก็กล่าวไว้เช่นนั้น แต่ยังมีข้อจำกัดสามประการ Mods ไม่ทำงานในแชทของ Claude และใน Cowork การตั้งค่าคอนโซลขององค์กรจะไม่มีผล ลำดับการทำงานของ mod มีเจ้าของสองรายคือองค์กรและบุคคล โดยไม่มีสายงานคั่นกลาง บนแผน Enterprise plugin ที่บังคับใช้กับกลุ่มหนึ่งสามารถพก mod ไปให้กลุ่มนั้นได้ แต่มันจะทำงานเป็นหนึ่งใน mod ของบุคคลนั้น โดยไม่มีลำดับความสำคัญ และ mod คือโค้ดที่ไม่ได้อยู่ใน sandbox: เพื่อให้ทำงานก่อน mod ของบุคคล mod ขององค์กรต้องอยู่ใน directory บนเครื่องแต่ละเครื่อง และการตั้งค่าที่ส่งมาจาก admin console “ไม่สามารถวาง directory บนเครื่องได้” บริษัทที่ไม่มีระบบจัดการอุปกรณ์สามารถ push mod ไปให้ทุกคนได้ แต่มันจะไปทำงานปะปนกับ mod ของบุคคล ไม่ได้ทำงานก่อนพวกเขา บริษัทไม่ควรต้องมานั่งเขียน TypeScript เพียงเพื่อจะบอกว่าแผนกหนึ่งใช้หน่วยวัดที่ต่างออกไป

“Memory จะเรียนรู้กฎเอง” Memory ถูกเขียนโดย Claude เป็นส่วนใหญ่ สำหรับบุคคลเดียวหรือโปรเจกต์เดียว และเจ้าของไม่สามารถอ่านหรือแก้ไข memory ของสมาชิกได้ ผู้ตรวจสอบต้องการกฎที่ถูกเขียนโดยบุคคล มีการควบคุมเวอร์ชัน ได้รับการอนุมัติ และติดตามย้อนกลับไปยังแต่ละคำตอบได้ Anthropic สร้างสิ่งนั้นมาแล้วสามครั้ง: สำหรับสิทธิ์ ด้วย “View effective role” และป้าย “Granted by”; สำหรับ skills และ plugins ด้วยประวัติเวอร์ชันและขั้นตอนการตรวจสอบที่ “คุณไม่สามารถอนุมัติของตัวเองได้”; และสำหรับการเข้าถึงของ Claude Tag ด้วยป้าย “Inherited from” แต่คำสั่งในโปรเจกต์ไม่มีสิ่งใดในสามสิ่งนี้เลย

“Claude Tag ก็ทำสิ่งนี้อยู่แล้ว” สำหรับ Slack channel ถือว่าใช่เป็นส่วนใหญ่ และหัวข้อ 1 ก็กล่าวไว้แล้ว แต่ยังมีสามสิ่งที่ขาดหายไป channel ไม่ใช่โปรเจกต์: มันไม่มีโฟลเดอร์ ไม่มี key ไม่มีวงจรชีวิต และ “channel ไม่สามารถชี้ไปที่ Project ได้” โครงสร้างต้นไม้มีสามระดับที่ตายตัว ดังนั้นบริษัทที่มีสายงานและมีงานหลายร้อยชิ้นจึงต้องยุบสองระดับให้แบนราบกลายเป็นชื่อ channel และเอกสารก็ไม่ได้อธิบายถึงการตรวจสอบความขัดแย้งตอนเขียนคำสั่ง; scope ต่าง ๆ ถูกนำมาต่อกันและปล่อยให้โมเดลไปจัดการปรับให้เข้ากันเอง ถ้าจะพูดอะไรสักอย่าง Claude Tag คือหลักฐานที่แข็งแกร่งที่สุดที่สนับสนุนการออกแบบในบทความนี้: บริษัทเดียวกันนี้เลือกการสืบทอด, credential ที่ผูกกับ scope และป้ายบอกที่มา เมื่อตอนที่สร้างระบบสำหรับทีม

“โครงสร้างลำดับชั้นเพิ่มความซับซ้อน” ก็ต่อเมื่อความลึกของมันไม่จำกัดเท่านั้น คำแนะนำของ Microsoft เองสำหรับ management groups คือ “ไม่เกินสามถึงสี่ระดับ” โมเดลนี้กำหนดระดับที่มีกฎตายตัวไว้ที่สี่ระดับ และโฟลเดอร์สำหรับจัดกลุ่มอย่างซีรีส์และปีไม่มีกฎใด ๆ เลย

“การสืบทอดเป็นความเสี่ยงด้านความปลอดภัย” ใช่ ถ้าคุณสืบทอดสิทธิ์การเข้าถึงอย่างไม่ระมัดระวัง คำตอบแบบคลาวด์ใช้ได้เสมอ: ต้องมี allow ในทุกระดับ, deny ที่จุดใดก็ได้จะชนะ, Claude ทำงานในฐานะผู้ใช้ที่ตัดกับ node และการแก้ไขกฎของ Claude เองจะกลายเป็นข้อเสนอ

“ยิ่งมีเลเยอร์มาก ยิ่งเปลือง token” หัวข้อ 3.2 วัดผลตรงกันข้ามใน Claude Code: token คำสั่งน้อยลง 20% เมื่อใช้ cascade และน้อยลง 34% เมื่อ compile เทียบกับการคัดลอกแบบแบนราบ ไฟล์ที่เพิ่มมาแต่ละไฟล์ย่อมมี overhead บ้าง ดังนั้นการ compile จึงดีกว่าการ cascade งานที่ระบุประเภทจะตัด template ที่ไม่ได้ใช้ออกไป และ prefix ที่ compile แล้วจะเหมือนกันทุก byte ข้ามโปรเจกต์ ดังนั้น prompt caching จึงนำกลับมาใช้ใหม่ได้ บน Claude API cache จะแยกกันตาม workspace ดังนั้นการมี workspace ต่อองค์กรจึงสอดคล้องกับ root ของต้นไม้ ทุกวันนี้ Claude Code ยังทำแบบนี้ไม่ได้: cache ของมัน scope อยู่ที่เครื่องและ directory เดียว

“ทีมก็ดูแลโปรเจกต์ของตัวเองไปสิ” นั่นคือวิธีแก้ปัญหาเฉพาะหน้าที่ใช้กันทุกวันนี้ และ prototype ในหัวข้อ 5 ก็ได้วัดแล้วว่าวิธีนี้ให้อะไร: สำเนาที่วางแปะ 2 จาก 6 ชุดล้าสมัยแล้วในการสาธิตขนาดเล็ก

5. มันทำงานได้แล้ววันนี้: reference implementation

เพื่อแสดงให้เห็นว่าโมเดลนี้สร้างได้จริง ไม่ใช่แค่เถียงกันได้ ผมจึงสร้าง Worktree ซึ่งเป็นแอปเดสก์ท็อปขนาดเล็ก (Node และ Electron, ผ่านการทดสอบ 24 รายการบน Windows และ Linux) มีเลย์เอาต์คล้าย Claude Desktop วิดีโอด้านบนคือการรันจริง ย่อเฉพาะช่วงที่ Claude กำลังทำงานเท่านั้น มันเป็นแอปแยกต่างหากที่สั่งงาน Claude Code จากภายนอก ไม่ใช่ mod มันไม่ได้เรียกใช้โมเดลของตัวเอง ทุกแชทจะรัน Claude Code ที่ติดตั้งอยู่ในเครื่องแล้ว (claude -p) ด้วยการเข้าสู่ระบบใดก็ตามที่ Claude Code มี: การสมัครสมาชิก Claude หรือ API key ผมทดสอบมันกับบริษัทสมมติที่มีสามสายงานและหกโปรเจกต์ เมื่อมีคนส่งข้อความ:

• Permit ผู้ใช้งานต้องมีสิทธิ์ในโปรเจกต์หรือระดับที่สูงกว่า และโปรเจกต์ต้องอยู่ในสถานะ open แอดมินที่ไม่มีสิทธิ์ในสายงานจะถูกหยุดก่อนที่ Claude จะเริ่มทำงาน

• Check การตรวจสอบตอนเขียนจะทำงานก่อน กฎ SI จากหัวข้อ 3.4 จะถูกปฏิเสธเพราะขัดแย้งกับกฎบริษัทแบบ enforced ดังนั้นมันจึงไม่มีวันไปถึง CLAUDE.md

• Mount โครงสร้างต้นไม้จะถูกเขียนลงในโฟลเดอร์โปรเจกต์จริงเป็นไฟล์ CLAUDE.md หนึ่งไฟล์ต่อระดับ (องค์กรอยู่ที่ storage root, จากนั้นเป็นสายงาน, แล้วจึงเป็นโปรเจกต์) และระบบ cascade ของ Claude Code จะโหลดพวกมัน โหมด compile จะเขียนหนึ่งไฟล์ต่อโปรเจกต์แทน ไฟล์ที่ไม่มี marker ของแอปจะไม่ถูกเขียนทับเด็ดขาด

• Run Template ของงานจะถูกใส่เข้าไปใน --append-system-prompt-file สิ่งที่ Claude ทำได้จะถูกบังคับโดย Claude Code ไม่ใช่โดย CLAUDE.md: --allowedTools คือ role ของบุคคลที่ตัดกับ policy ของทุกระดับ, การเขียนถูกจำกัดไว้ที่โฟลเดอร์โปรเจกต์ และ --permission-mode dontAsk จะปฏิเสธทุกอย่างที่เหลือ ในการรันจริง การค้นหาเว็บถูกปฏิเสธเพราะ policy ของสายงานไม่อนุญาตให้ใช้ web และการเขียนนอกโฟลเดอร์โปรเจกต์ถูกปฏิเสธและบันทึก log ไว้

• Log and review ทุกคำตอบจะถูกบันทึก log พร้อมชื่อบุคคล, node, แท็กกฎทุกอัน, กฎที่ Claude อ้างอิง และ token ประเภท input, cache และ output ที่ Claude Code รายงาน ผู้ตรวจสอบที่ไม่ได้เป็นคนเขียนคำตอบจะเป็นผู้ยอมรับหรือตีกลับ การรัน density-report จริงในการสาธิตใช้เวลาประมาณ 30 วินาที; จากการรันสามครั้ง Claude Code รายงานต้นทุน $0.08–0.22 ต่อคำตอบตามราคา list price Claude อ้างอิงกฎที่มันใช้ แจ้งเตือนผลลัพธ์ที่เฉียดขีดจำกัดการยอมรับ และเว้นฟิลด์ของวิศวกรไว้ว่างเปล่า

• Drift ทุก CLAUDE.md ที่ mount ไว้จะถูกเปรียบเทียบกับโครงสร้างต้นไม้ และการแก้ไขด้วยมือจะถูกแจ้งเตือน Prototype แบบ command-line ก่อนหน้านี้ทำการเปรียบเทียบเดียวกันกับสำเนาที่วางแปะในโปรเจกต์แบบแบนราบ และพบว่า 2 จาก 6 ชุดล้าสมัย: ชุดหนึ่งยัง停留在 R-07 v3 และอีกชุดหนึ่งที่กฎถูกลบออกด้วยมือ

ข้อค้นพบสามข้อจากการสร้างมัน ซึ่งเกี่ยวข้องกับทุกคนที่กำลังซ้อนเลเยอร์คำสั่งบน Claude Code:

1. คำสั่งส่วนตัวของคุณรั่วไหลเข้าไปในการรันขององค์กร โดยค่าเริ่มต้น การรันทุกครั้งจะโหลด ~/.claude/CLAUDE.md, กฎ, agent และเซิร์ฟเวอร์ MCP ส่วนตัวของผมด้วย ตอนนี้แอปยกเว้นสิ่งเหล่านั้นด้วยการตั้งค่า claudeMdExcludes บวกกับ --strict-mcp-config บนเครื่องของผม สิ่งนี้ลด context ของการรันจาก 29.6k เหลือ 21.4k tokens ทางเลือกที่ชัดเจนอย่าง --setting-sources project,local กลับทำตรงกันข้ามกับที่ต้องการใน Claude Code 2.1.284 บน Windows: มันเก็บไฟล์ส่วนตัวไว้และทิ้งไฟล์ CLAUDE.md ของโฟลเดอร์ parent ที่พกข้อมูลองค์กรและสายงานไปเสีย

1. Mod ของบุคคลก็รั่วเข้ามาด้วย Mods เปิดตัวหนึ่งวันหลังจากที่แอปสร้างเสร็จ ผมจึงทดสอบมัน ผมติดตั้ง mod แบบ one-hook ใน user scope ของตัวเองที่เพิ่มบรรทัดข้อความในทุกพรอมต์ มันเข้าถึงการรันของแอปได้: กฎสามข้อขององค์กรถูกโหลด และบรรทัดส่วนตัวของผมก็ถูกโหลดด้วย และคำตอบก็เชื่อฟังมัน การเพิ่ม disableAllHooks ในการตั้งค่าของการรันช่วยกันมันออกไปและปล่อยให้ CLAUDE.md สามระดับอยู่ครบถ้วน ตอนนี้แอปทำสิ่งนี้แล้ว --safe-mode ใช้แทนกันไม่ได้: มันลบ mod ออกพร้อมกับระบบ cascade ของ CLAUDE.md ทั้งหมด ตามเอกสาร การใช้ disableAllHooks ในการตั้งค่าของบุคคลเองจะปล่อยให้สิ่งที่องค์กรบริหารจัดการทำงานต่อไปได้

1. CLAUDE.md คือ context การบังคับใช้คือ configuration เอกสารของ Anthropic ระบุไว้เช่นนั้น: “กฎการตั้งค่าจะถูกบังคับใช้โดยไคลเอนต์โดยไม่สนใจว่า Claude จะตัดสินใจทำอะไร คำสั่งใน CLAUDE.md กำหนดพฤติกรรมของ Claude แต่ไม่ใช่เลเยอร์การบังคับใช้ที่เข้มงวด” แอปนี้พึ่งพาสิ่งนั้น ทุกอย่างที่กฎต้องรับประกันจะถูกแมปไปยังสิทธิ์ของเครื่องมือ; ทุกอย่างใน CLAUDE.md คือคำแนะนำที่มาพร้อมกับแท็ก

มันทำงานได้บน Claude Code ในปัจจุบัน และข้อความที่ compile แล้วสามารถวางแปะในแชทหรือคำสั่งของโปรเจกต์ Cowork ได้ในทุกแผน มี dependency หนึ่งอย่างที่อาจหมดอายุ: แอปพึ่งพาการที่ claude -p โหลดไฟล์ CLAUDE.md และเอกสารของ Anthropic บอกว่า --bare ซึ่งจะข้ามไฟล์เหล่านั้น “จะกลายเป็นค่าเริ่มต้นสำหรับ -p ในเวอร์ชันอนาคต” เมื่อถึงเวลานั้น แอปจะต้องส่งโครงสร้างต้นไม้ด้วยวิธีอื่น; โหมด compile และ --append-system-prompt-file ทำได้แล้วตั้งแต่ตอนนี้ มันคือ specification ที่ใช้งานได้สำหรับเวอร์ชัน native ไม่ใช่ขอบเขตด้านความปลอดภัย: ฟังก์ชัน “acting as” เป็นเพียงสวิตช์สำหรับสาธิต ไม่ใช่การลงชื่อเข้าใช้

6. เส้นทางจากสิ่งที่ปล่อยออกมาแล้ว

ใน Claude Code ตอนนี้เลย ตั้งแต่วันที่ 1 ตุลาคม เป็นต้นมา โครงสร้างแบบ tree สามารถส่งมอบได้ในรูปแบบ mod: คอมไพล์กฎของโหนดเข้าไปเป็นส่วนหนึ่งของ system prompt ปฏิเสธการเรียกใช้ tool ที่นโยบายของโหนดไม่อนุญาต และแสดงคำสั่งที่มีผลบังคับใช้จริงในหน้าต่างแยก องค์กรสามารถรัน mod นั้นก่อนสิ่งใด ๆ ที่ผู้ใช้แต่ละคนติดตั้งเข้ามา ผมยังไม่ได้สร้างสิ่งนี้ขึ้นมา มันเป็นรายการแรกใน roadmap ของ reference implementation ซึ่งจะครอบคลุมถึง Claude Code และอาจรวมถึงเซสชัน Cowork บนเครื่องของผู้ใช้ที่ทำงานบนเอนจินเดียวกัน แต่จะไม่ครอบคลุมส่วนแชท

เวอร์ชัน 30 วัน สำหรับแชทและ Cowork Anthropic มีชิ้นส่วนทั้งหมดพร้อมอยู่แล้ว แค่ให้โปรเจกต์หนึ่งระบุชื่อโปรเจกต์แม่ที่จะสืบทอดคำสั่งมาได้ เหมือนกับที่ช่อง Slack สืบทอดจาก workspace ของมันใน Claude Tag จากนั้นคอมไพล์ทั้งสองตามลำดับ พร้อมติดแท็กไว้ทุกกฎ แล้วเพิ่มแผง “View effective instructions” ไว้ข้าง ๆ “View effective role” ที่มีอยู่เดิม แค่นี้ก็ทำให้ทุกสายงานมีที่เก็บกฎของตัวเองเป็นที่เป็นทางแล้ว

หลังจากนั้น แต่ละขั้นตอนก็มีประโยชน์ในตัวเอง โดยเริ่มจากสิ่งที่ช่วยแผน Team ก่อน:

1. โหนดสำหรับสายงานและการจัดเตรียม key-pattern โดยนำ semantic ของ CLAUDE.md ที่ใช้งานได้ดีอยู่แล้วในโค้ดกลับมาใช้ใหม่ ในตัว Claude Code เอง ขั้นตอนการจับคู่ (matching) จะทำหน้าที่เป็นระดับขั้นสำหรับกลุ่มที่อยู่ระหว่าง mod ขององค์กรกับ mod ของบุคคล รวมถึงการตั้งค่าแบบ managed แยกตามกลุ่ม

1. ประเภทงาน (Task types) ในฐานะทักษะที่จำกัดขอบเขตไว้ในแต่ละสายงาน พร้อมเกณฑ์การยอมรับ (acceptance criteria)

1. การตรวจสอบความขัดแย้งขณะเขียน เพื่อให้โครงสร้าง tree เป็นตัวปฏิเสธข้อความที่ขัดแย้งกันเอง ไม่ใช่ปล่อยให้โมเดลมาตัดสินชี้ขาด

1. การกำหนดสิทธิ์ (Grants) บนโหนด ซึ่งใช้งานได้บนแผน Team แม้ไม่มีกลุ่ม และต่อยอดจากระบบ custom roles ของ Enterprise

1. Connector identities ที่ผูกกับ branch สำหรับโปรเจกต์ เหมือนกับที่ Claude Tag ผูก service account เข้ากับช่อง Slack อยู่แล้ว

1. การบันทึกการใช้งานรายโหนด ที่อ้างอิงตามโปรเจกต์ เหมือนที่ Claude Tag รายงานแยกตามช่องอยู่แล้ว พร้อมการประกาศขีดจำกัดรายสัปดาห์ในหน่วยที่ระบุชัดเจน และการเปิดเผยข้อมูลการใช้พลังงานต่อแต่ละงาน

7. ข้อจำกัด

• ความครอบคลุม เมื่อวันที่ 1 ตุลาคม 2026 ดัชนีหน้าทั้งหมดของ code.claude.com/docs และ claude.com/docs ถูกคัดกรองตามหัวข้อ (466 หน้า) และมีประมาณ 150 หน้าที่ถูกอ่านอย่างละเอียด พร้อมกับบทความจาก help-center ที่อ้างอิงไว้ในนี้ บทความเวอร์ชันก่อนหน้าพลาดเรื่อง Claude Tag ไปทั้งหมด ส่วนเวอร์ชันนี้อาจพลาดเรื่องอื่นไปก็ได้ มีการกล่าวถึง Claude for Government และ Claude Desktop บนผู้ให้บริการ third-party แต่ไม่ได้ลงลึกวิเคราะห์

• ฟีเจอร์ต่าง ๆ ของแพลตฟอร์มเปลี่ยนแปลงทุกเดือน และมีฟีเจอร์หนึ่งที่เปลี่ยนไปขณะที่กำลังเขียนบทความนี้ ทุกคำกล่าวอ้างเกี่ยวกับผลิตภัณฑ์ในบทความนี้อ้างอิงช่วงเวลา 29 กันยายน – 1 ตุลาคม 2026 และควรตรวจสอบอีกครั้งก่อนนำไปใช้จริง Mods เพิ่งเปิดตัวได้แค่วันเดียว ผมอ่านเอกสารและทดสอบไปหนึ่งกรณีเท่านั้น ยังไม่ได้เอาไปใช้ในระบบ production จริง

• ตัวเลขที่วัดได้ ในหัวข้อ 3.1–3.4 มาจากรายงานการใช้งานของ Claude Code เอง แบ่งเป็นสองชุด: Claude Code 2.1.286 เมื่อวันที่ 2026-09-30 และ 2.1.287 เมื่อวันที่ 2026-10-01 ทั้งสองชุดรันบน Claude Sonnet 5.5 สคริปต์ ข้อมูลทั้งสองชุด และคำตอบทั้งหมดถูกเก็บไว้โดยผู้เขียนและสามารถขอรับได้ ประกอบด้วย prompt ของ Claude Code เอง (ประมาณ 30,200 tokens) ซึ่ง claude.ai และ Cowork ไม่ได้ใช้ร่วมกัน และครอบคลุมเพียงหนึ่งโมเดล หนึ่งโปรเจกต์สาธิต และหนึ่งคำถาม ขนาดตัวอย่างถือว่าน้อย: สิบคำตอบต่อเงื่อนไขสำหรับการวัดความยาวคำตอบ และยี่สิบคำตอบต่อเงื่อนไขสำหรับการทดสอบความขัดแย้ง อัตราส่วนความยาวคำตอบมีการเปลี่ยนแปลงระหว่างสองชุดข้อมูล (หัวข้อ 3.3) นอกจากนี้ข้อมูลที่ห่างกันหนึ่งวันยังต่างกันที่เวอร์ชันของ Claude Code ด้วย ซึ่งผมไม่สามารถแยกแยะได้ว่าเกิดจากความบังเอิญหรือไม่

• เวลาในการรัน ต้นทุน และขนาด context ในหัวข้อ 5 มาจาก log คำตอบของแอปเองจากการรันสาธิตสามครั้งและการทดสอบ isolation แบบ manual อีกหนึ่งครั้ง ซึ่งเป็นบันทึกของผู้เขียนเอง

• คำตอบเรื่องการจัดการความขัดแย้ง ถูกเข้ารหัสโดยผู้เขียนแบบ unblinded ด้วยการอ่านทุกคำตอบ (รายงานหน่วยที่ใช้; คำตอบระบุว่ากฎไหนชนะและเพราะอะไรหรือไม่; มีการถามกลับหรือไม่) ทั้งสี่สิบคำตอบสามารถขอรับเพื่อนำไปเข้ารหัสใหม่ได้ การทดสอบใช้คำว่า "enforced" เพียงรูปแบบเดียว การใช้ถ้อยคำ โมเดล หรือคู่กฎอื่น ๆ อาจให้ผลลัพธ์ที่ต่างออกไป

• การทดสอบ mod ในหัวข้อ 5 ใช้หนึ่ง mod กับหนึ่ง hook บนเครื่อง Linux หนึ่งเครื่อง รันด้วย Claude Haiku ล็อกอินด้วยบัญชีแบบ subscription และไม่มีการตั้งค่า managed settings ผมไม่ได้ทดสอบ policy mod ระดับองค์กร ระบบป้องกันในตัวเมื่อล็อกอินผ่าน Team หรือ Enterprise หรือแอป Desktop

• โมเดลต้นทุน ในหัวข้อ 3.2 เป็นการจำลองสถานการณ์ของบริษัทสมมติ ไม่ใช่ตัวเลขบิลจริง ครอบคลุมเฉพาะ instruction tokens เท่านั้น ในขณะที่ประวัติการสนทนา output และ thinking มักกินสัดส่วนหลักในบิลจริง ขนาด token ใช้ legacy tokenizer สาธารณะของ Anthropic คูณ 1.30 ในการวัดจริง Claude Code โหลดมากกว่าค่าประมาณนั้น 21–26% ทำให้ตัวเลขดอลลาร์ที่แสดงออกมาต่ำกว่าความเป็นจริง เปอร์เซ็นต์ที่ระบุเป็นอัตราส่วนซึ่งยังคงเชื่อถือได้ รูปแบบเซสชันและการแชร์ cache เป็นข้อสมมติฐาน

• ยังไม่มีเอกสารระบุว่าการใช้งานแชทบน Enterprise ได้รับราคา API cache หรือไม่ และ cache บน claude.ai ถูกแชร์ข้ามผู้ใช้หรือไม่ Cowork รันเซสชันของมันบน Claude Code และ plugin hooks ก็โหลดที่นั่น แต่หน้า docs เรื่อง mods ไม่ได้ระบุถึง Cowork และผมก็ไม่ได้ทดสอบมัน ณ วันที่ 1 ตุลาคม แอป desktop ยังคงรวม Claude Code 2.1.286 มาให้ ซึ่งเป็นเวอร์ชันก่อนที่ mods จะเปิดใช้งาน นโยบาย managed ของอุปกรณ์ส่งผลถึงเซสชัน Cowork บนเครื่องของผู้ใช้ เว้นแต่องค์กรจะเลือกให้รันใน VM sandbox แบบเต็มรูปแบบ มีเอกสารสองหน้าที่ให้ข้อมูลขัดแย้งกันว่าไฟล์ ~/.claude ของผู้ใช้จะถูกส่งไปถึง Cowork หรือไม่ บทความนี้จึงไม่วินิจฉัยในเรื่องนี้ ผมยังไม่ได้ทดสอบว่าไฟล์ CLAUDE.md ในโฟลเดอร์แม่จะถูกโหลดในเซสชัน Cowork หรือไม่ ถ้าโหลดได้ โครงสร้าง tree ที่ mount ไว้ใน reference implementation ก็จะส่งผลถึง Cowork บนเครื่องผู้ใช้ได้แล้วในวันนี้ สำหรับแผน Pro และ Max ช่องว่างนี้จะแคบลงในวันที่ 6 ตุลาคม 2026 เมื่อ task ใหม่ของ Cowork ย้ายไปรันบนคลาวด์

• แรงจูงใจต่าง ๆ เป็นการอนุมาน Anthropic ยังไม่เคยอธิบายต่อสาธารณะว่าทำไมแชทของ Claude และ Cowork จึงมีโครงสร้างแบบแบนราบ

• ซอร์สโค้ดและข้อมูลดิบไม่ได้เผยแพร่พร้อมกับบทความนี้ ผู้อ่านไม่สามารถทำซ้ำผลการวัดได้จากบทความเพียงอย่างเดียว วิดีโอแสดงให้เห็นว่าแอปทำงานอย่างไร ไม่ใช่สร้างขึ้นมาอย่างไร

• Reference implementation ทำงานบนบริษัทสมมติ มันไม่ได้เชื่อมต่อกับ claude.ai หรือ Cowork และฟังก์ชัน "acting as" เป็นเพียงสวิตช์สำหรับสาธิต ไม่ใช่การล็อกอิน การควบคุมสิทธิ์ทำผ่าน tool lists ของ Claude Code ไม่ใช่ผ่านตัวแอป การทำ isolation จะปิด hooks และ mods ส่วนตัวของผู้นั้นระหว่างการรัน แต่ mods ที่ฝังมากับ Claude Code จะยังทำงานต่อไป และชื่อ personal agents ก็ยังปรากฏใน context ได้ แอปพึ่งพาการทำงานของ claude -p ในการโหลด CLAUDE.md ซึ่ง Anthropic บอกว่าจะไม่เป็นค่าเริ่มต้นอีกต่อไป ปัญหาการรั่วไหลของไฟล์ส่วนตัวและผลลัพธ์ของ --setting-sources ถูกทดสอบบน Windows ส่วนการวัดผลและการทดสอบ mod ทำบน Linux

แหล่งอ้างอิง

• Anthropic, Set organization instructions

• Anthropic, Roles and permissions

• Anthropic, What is the Team plan? · Plans and pricing

• Anthropic, Manage custom roles on Enterprise plans

• Anthropic, Organize your tasks with projects in Claude Cowork

• Anthropic, Use Google Workspace connectors

• Anthropic, Manage groups and group spend limits on Enterprise plans

• Anthropic, What are projects? (เวอร์ชันใหม่ของ projects, beta)

• Anthropic, Get started with Claude Cowork(คำสั่งระดับ global และ folder)

• Anthropic, How Claude remembers your project (CLAUDE.md) · All settings (claudeMdExcludes, disableAllHooks)

• Anthropic, Customize Claude Code with mods (1 ตุลาคม 2026) · Mods overview · Manage mods for your organization · React to events with a mod · Mods reference

• Anthropic, Claude Tag: What is Claude Tag? · Configure per-channel access · Customize Claude Tag · How agent identity works · Audit · Set a spend limit

• Anthropic, Projects in Claude Code (new projects beta) · Projects in Cowork · How Claude Code uses prompt caching · Run Claude Code programmatically (--bare) · Extend Claude Code · Manage project visibility and sharing · Use connectors · Authorize MCP connectors for your entire organization · Provision and manage skills

• Anthropic, Configure server-managed settings (ไม่มีการตั้งค่าแยกตามกลุ่ม) · Manage plugins for your organization (ความพร้อมใช้งานของ plugin แยกตามกลุ่มบน Enterprise) · Plugin feature support across platforms (hooks ถูกละเว้นในแชท แต่โหลดใน Cowork) · Deploy managed settings (Cowork รันเซสชันบน Claude Code)

• Anthropic, Pricing (อัตราของ Sonnet 5.5, หมายเหตุเรื่อง tokenizer) · Prompt caching (cache แยกตามองค์กรและตาม workspace บน API)

• Anthropic, @anthropic-ai/tokenizer(tokenizer สาธารณะที่ใช้ในการนับจำนวน)

• Microsoft, Management groups · Landing-zone management group design

• AWS, SCP evaluation · Google Cloud, Hierarchy evaluation

• Microsoft, Group Policy processing · SharePoint fine-grained permissions

• FinOps Foundation, Token economics

• Jaroslawicz et al., How Many Instructions Can LLMs Follow at Once? (IFScale)

• Firefly, 2026 State of IaC research

• MCP, Authorization specification, version 2026-07-28

• GitHub, anthropics/claude-code issues #68262, #14467, #30554, #27567, #30250, #27302, #47741

• Beer, S. (1979), The Heart of Enterprise; Alexander, C. (1965), “A City is Not a Tree,” Architectural Forum; Simon, H. (1962), “The Architecture of Complexity,” Proc. Am. Phil. Soc.106(6)

• Reference implementation และข้อมูล: แอป Worktree ชุดการทดสอบ สคริปต์วัดผล ผลลัพธ์ทั้งสองชุด และคำตอบทั้งหมด เก็บรักษาไว้โดยผู้เขียนและสามารถขอรับได้