AutoBE và Claude Code: Đánh Giá Chuyên Sâu Mã Nguồn Rò Rỉ Từ Nhà Phát Triển Agent Lập Trình AI Thế Hệ 3

Vụ Rò Rỉ Chấn Động: Mã Nguồn Claude Code Bị Lộ

Tháng 4 năm 2026, một sự cố gây chấn động trong cộng đồng lập trình viên đã xảy ra. Một kỹ sư của Anthropic vô tình chạy lệnh npm publish mà không có file .npmignore, khiến toàn bộ mã nguồn của Claude Code bị tải lên kho lưu trữ npm công khai. Đây là một sai lầm nhỏ nhưng hậu quả lớn, phơi bày kiến trúc nội bộ của một trong những tác nhân mã hóa AI được sử dụng rộng rãi nhất trên thế giới.

Chỉ trong vài giờ, Anthropic đã gỡ bỏ gói này, nhưng hàng ngàn nhà phát triển đã kịp tải xuống mã nguồn. Các diễn đàn như Reddit, Hacker News và X nhanh chóng tràn ngập các phân tích về Claude Code. Từ các lời nhắc hệ thống (system prompts) cho đến kiến trúc bảo mật hay cấu trúc của vòng lặp while(true) đều được mổ xẻ chi tiết.

Đối với đội ngũ phát triển AutoBE, sự kiện này không chỉ là một tin tức hot mà còn là một “món quà” đúng lúc. AutoBE đang ở một “điểm uốn” quan trọng, chuẩn bị tăng cường khả năng điều phối phức tạp cho một quy trình vốn được giữ đơn giản. Nhu cầu nghiên cứu cách các tác nhân AI khác thiết kế cơ chế điều phối của họ trở nên cấp thiết hơn bao giờ hết. Và sai lầm đóng gói của Anthropic đã cung cấp một kiến trúc tham chiếu hoàn hảo.

Mã nguồn Claude Code không chỉ đơn thuần là một dự án lớn, mà còn là cả một “triết lý”. Nó bao gồm bảy đường dẫn phục hồi trong một vòng lặp while(true), cơ chế nén ngữ cảnh bốn tầng, hai mươi ba danh mục kiểm tra bảo mật, và hơn 400KB mã bảo mật chỉ riêng cho BashTool. Càng đi sâu phân tích, đội ngũ AutoBE càng nhận ra rõ ràng lý do tại sao họ lại xây dựng mọi thứ theo một cách hoàn toàn khác biệt. Bài viết này là tổng hợp những ghi chú và phân tích đó.

AutoBE: Nhà Máy Backend Tự Động Hóa AI Thế Hệ 3

AutoBE là một tác nhân AI mã nguồn mở có khả năng tự động tạo ra các hệ thống backend. Chỉ với một yêu cầu đơn giản như “xây dựng backend cho một trung tâm mua sắm”, AutoBE sẽ tạo ra mọi thứ, từ phân tích yêu cầu, thiết kế cơ sở dữ liệu, đặc tả API, kiểm thử E2E cho đến mã triển khai NestJS—tất cả cùng một lúc.

Nhờ vào kỹ thuật Function Calling Harness và các trình biên dịch AI-native, AutoBE đảm bảo chất lượng đầu ra được tạo ra. Ngay cả các mô hình nhỏ như qwen3.5-35b-a3b cũng có thể sản xuất các hệ thống backend ngang tầm với các mô hình hàng đầu—với chi phí thấp hơn đáng kể.

• Hiện tại, AutoBE hỗ trợ stack TypeScript / NestJS / Prisma.
• Kế hoạch mở rộng sang các ngôn ngữ và framework khác dự kiến bắt đầu vào tháng 7 năm 2026.

LLM Không Trực Tiếp Viết Mã

Hầu hết các tác nhân mã hóa AI đều yêu cầu LLM “viết mã này” và lưu văn bản trả về vào một tệp. AutoBE hoạt động khác biệt.

AutoBE sử dụng **Function Calling**. Thay vì văn bản tự do, LLM điền vào một JSON Schema được định nghĩa trước—một Cây Cú Pháp Trừu Tượng (AST). Nó không viết trên một trang giấy trắng; nó điền vào một biểu mẫu. Sau khi biểu mẫu được điền, một trình biên dịch sẽ xác thực nó và chuyển đổi thành mã thực tế. **LLM điền vào cấu trúc; trình biên dịch viết mã.**

Nguyên tắc này áp dụng cho toàn bộ quy trình 5 giai đoạn:

| Stage        | Structure the LLM fills                  | Compiler validation        |
| ---          | ---                                      | ---                        |
| Requirements | `AutoBeAnalyze`—structured SRS           | Structure validation       |
| DB Design    | `AutoBeDatabase`—DB schema AST           | Database Compiler          |
| API Design   | `AutoBeOpenApi`—OpenAPI v3.2 spec        | OpenAPI Compiler           |
| Testing      | `AutoBeTest`—30+ expression types        | Test Compiler              |
| Implementation | Modularized code (Collector/Transformer/Operation) | Hybrid Compiler            |

Mỗi AST giới hạn nghiêm ngặt những gì LLM có thể tạo ra. Ví dụ, AutoBeDatabase chỉ cho phép 7 kiểu trường: "boolean" | "int" | "double" | "string" | "uri" | "uuid" | "datetime". Bạn không thể sử dụng "varchar"—nó đơn giản là không có sẵn. **Schema chính là lời nhắc**—rõ ràng, độc lập với mô hình và có thể kiểm chứng bằng máy móc.

Tại Sao Lại Là Function Calling?

“Không thể chỉ để LLM viết trực tiếp mã văn bản sao?”

Với frontend, có thể. Nếu một nút bấm hơi lệch vị trí hoặc một hoạt ảnh trông không ổn, ứng dụng vẫn hoạt động. Trên di động, bạn có thể vá lỗi sau khi ra mắt. Nhưng **backend thì khác.**

Phát triển backend không phải là lĩnh vực của sự sáng tạo—**nó là lĩnh vực của logic và độ chính xác.** Nếu một API duy nhất trả về kiểu dữ liệu sai, mọi client đều gặp lỗi. Nếu thiếu một khóa ngoại, tính toàn vẹn dữ liệu sẽ mất đi. Nếu hai API định nghĩa cùng một thực thể khác nhau, hệ thống sẽ mâu thuẫn nội bộ. Lỗi frontend là một bất tiện; lỗi backend là một sự cố ngừng hoạt động—backend là nguồn chân lý duy nhất mà mọi client phụ thuộc vào. **Tính nhất quán và độ chính xác 100% là các điều kiện tiên quyết không thể thương lượng**, không phải là những tính năng bổ sung.

Tạo văn bản tự do không thể đáp ứng yêu cầu này về mặt cấu trúc.

Không Thể Kiểm Soát

Bạn có thể áp đặt tính nhất quán thông qua các lời nhắc không? “Không dùng varchar,” “không dùng kiểu any,” “không tạo hàm tiện ích”—đây là vấn đề voi hồng. Nói với ai đó “đừng nghĩ về một con voi hồng,” và điều đầu tiên họ làm là hình dung nó. Nói với LLM “đừng làm X,” và X trở thành trung tâm chú ý, thực sự **tăng khả năng tạo ra nó**. Ngôn ngữ tự nhiên chỉ có thể diễn đạt các ràng buộc thông qua sự cấm đoán, và **sự cấm đoán không đầy đủ về mặt cấu trúc.**

export namespace AutoBeDatabase {
  export interface IForeignField {
    name: string & SnakeCasePattern; // enforce snake_case naming
    type: "uuid";
    relation: IRelation;
    unique: boolean;
    nullable: boolean;
  }
  export interface IPlainField {
    name: string & SnakeCasePattern;
    type: // restrict type by spec, not by prohibition rule
      | "boolean"
      | "int"
      | "double"
      | "string"
      | "uri"
      | "uuid"
      | "datetime";
    description: string;
    nullable: boolean;
  }
}

Function Calling giải quyết vấn đề này tận gốc. LLM không viết trên một trang giấy trắng—nó điền vào một biểu mẫu đã định nghĩa trước. Chỉ có 7 kiểu trường; các đặc tả API tuân theo schema OpenAPI v3.2; logic kiểm thử chỉ có thể được diễn đạt trong 30 biến thể của IExpression. Không phải “không dùng varchar”—varchar đơn giản là không tồn tại như một lựa chọn. **Không phải cấm đoán, mà là sự vắng mặt.** Giao tiếp thông qua các kiểu và không có sự hiểu lầm; ràng buộc thông qua các schema và không có voi hồng.

Hiệu Ứng Cộng Gộp

Phép toán của backend không khoan nhượng. Hãy xem xét một dịch vụ với 50 bảng và 400 API. Tất cả 400 API phải thành công để máy chủ chạy. Tỷ lệ thành công tổng cộng = (tỷ lệ thành công trên mỗi đơn vị)^n:

| Tỷ lệ thành công mỗi đơn vị | 10 API | 50 API | 100 API | 400 API |
| ---                        | ---    | ---    | ---     | ---     |
| 95%                        | 59.9%  | 7.7%   | 0.6%    | ~ 0%    |
| 99%                        | 90.4%  | 60.5%  | 36.6%   | 1.8%    |
| 99.9%                      | 99.0%  | 95.1%  | 90.5%   | 67.0%   |
| <strong>100%</strong>                 | <strong>100%</strong>   | <strong>100%</strong>   | <strong>100%</strong>    | <strong>100%</strong>    |

Đây là giới hạn cấu trúc của việc tạo văn bản tự do. Đưa cho một trợ lý mã hóa một backend với 50 bảng và 400 API, và bạn sẽ nhận được đầu ra. **Từ 0 đến 80 thì nhanh.** Khung sườn rất tốt, các hàm riêng lẻ được viết tốt. Nhưng để có 400 API nhất quán lẫn nhau, với mọi khóa ngoại được kết nối đúng cách và các kiểu dữ liệu dùng chung đồng nhất trên tất cả các điểm cuối—đó là **từ 80 đến 100**, một vùng mà việc tạo văn bản tự do không thể đạt được về mặt cấu trúc. Chừng nào tỷ lệ thành công của mỗi API là 95%, tổng tỷ lệ thành công sẽ hội tụ về 0 khi số lượng API tăng lên. Một con người có thể xem xét tất cả 400 API từng cái một, nhưng thế thì mục đích của AI là gì?

Function Calling giải quyết triệt để vấn đề cộng gộp này. Biểu mẫu được cố định, nên phương sai bằng 0; một trình biên dịch xác thực biểu mẫu, nên tỷ lệ thành công trên mỗi đơn vị hội tụ về 100%. **1.0^400 = 1.0.** Hơn nữa, một trình biên dịch 4 giai đoạn đảm bảo tính nhất quán cấp hệ thống—kiểm tra chéo giữa schema DB và đặc tả API, tính đồng nhất của các kiểu dùng chung trên các API, phát hiện các phụ thuộc vòng tròn giữa các module. Nếu xác thực thất bại, một vòng lặp tự sửa lỗi sẽ lặp lại cho đến khi thành công.

Phương Sai

Đầu ra của LLM là một mẫu được rút ra từ phân phối xác suất. Chạy cùng một mô hình với cùng một lời nhắc và bạn sẽ nhận được mã khác nhau mỗi lần—tên biến khác nhau, mẫu khác nhau, cách xử lý lỗi khác nhau. Thay đổi mô hình và sự khác biệt lớn hơn. Claude thiên về chức năng, GPT thiên về lớp, Qwen có các thành ngữ riêng. Phương sai này là sự phong phú trong viết sáng tạo, nhưng là một khiếm khuyết trong backend.

Khi biểu mẫu được cố định, phương sai biến mất. Schema AST thống nhất quản lý “phong cách” của mô hình, và trình biên dịch xác minh kết quả, nên “tính cách” của mô hình có tác động tối thiểu đến đầu ra cuối cùng. Các bài kiểm tra hiệu năng chứng minh điều này:

Các backend được tạo bởi qwen3.5-35b-a3b (3B hoạt động) và claude-sonnet-4.6 có kiến trúc, cấu trúc module và quy ước đặt tên gần như giống hệt nhau. Các mô hình mạnh hội tụ trong 1-2 lần lặp; các mô hình yếu hơn hội tụ trong 3-4 lần—nhưng đích đến là như nhau. **Các mô hình khác nhau, cùng một kết quả. Chạy lại, cùng một kết quả.** Đây là tính nhất quán mà backend yêu cầu, và Function Calling là cách tiếp cận duy nhất có thể đảm bảo điều đó về mặt cấu trúc.

Đồng Thuận Trong Ngành: “Việc Đó Sẽ Không Hoạt Động”

Nhưng các biểu mẫu mà LLM phải điền vào không hề đơn giản. <a href="https://github.com/wrtnlabs/autobe/blob/main/packages/interface/src/interface/AutoBeOpenApi.ts">AutoBeOpenApi.IJsonSchema</a>, định nghĩa các kiểu DTO, là một kiểu union đệ quy với 10 biến thể:

export type IJsonSchema =
  | IJsonSchema.IBoolean
  | IJsonSchema.IInteger
  | IJsonSchema.INumber
  | IJsonSchema.IString
  | IJsonSchema.IArray      // items: IJsonSchema <- recursive
  | IJsonSchema.IObject     // properties: Record<string, IJsonSchema> <- recursive
  | IJsonSchema.IReference
  | IJsonSchema.IOneOf      // oneOf: IJsonSchema[] <- recursive
  | IJsonSchema.INull
  | IJsonSchema.IConstant;

Mười biến thể lồng nhau 3 cấp độ tạo ra 1.000 đường dẫn khả thi.

Giai đoạn kiểm thử còn phức tạp hơn. <a href="https://github.com/wrtnlabs/autobe/blob/main/packages/interface/src/test/AutoBeTest.ts">AutoBeTest.IExpression</a>, đại diện cho logic kiểm thử E2E, có **hơn 30 biến thể đệ quy**—độ phức tạp ở cấp độ ngôn ngữ lập trình được gói gọn trong một lệnh Function Call duy nhất:

export type IExpression =
  | IBooleanLiteral   | INumericLiteral    | IStringLiteral     // literals
  | IArrayLiteralExpression  | IObjectLiteralExpression          // compound literals
  | INullLiteral      | IUndefinedKeyword                       // null/undefined
  | IIdentifier       | IPropertyAccessExpression               // accessors
  | IElementAccessExpression | ITypeOfExpression                 // access/operations
  | IPrefixUnaryExpression   | IPostfixUnaryExpression           // unary operations
  | IBinaryExpression                                            // binary operations
  | IArrowFunction    | ICallExpression    | INewExpression      // functions
  | IArrayFilterExpression   | IArrayForEachExpression           // array operations
  | IArrayMapExpression      | IArrayRepeatExpression            // array operations
  | IPickRandom       | ISampleRandom      | IBooleanRandom     // random generation
  | IIntegerRandom    | INumberRandom      | IStringRandom      // random generation
  | IPatternRandom    | IFormatRandom      | IKeywordRandom     // random generation
  | IEqualPredicate   | INotEqualPredicate                      // assertions
  | IConditionalPredicate    | IErrorPredicate;                  // assertions

Đây là độ phức tạp thực tế của biểu mẫu mà LLM phải điền chính xác trong một lệnh Function Call duy nhất.

Tỷ lệ thành công thử nghiệm đầu tiên của qwen3-coder-next trên IJsonSchema: **6.75%**. Đồng thuận của ngành là rõ ràng—NESTFUL (EMNLP 2025) đo lường độ chính xác của GPT-4o trong việc gọi công cụ lồng nhau là 28%, và JSONSchemaBench (ICLR 2025) báo cáo tỷ lệ thành công từ 3-41% ở tầng khó nhất trên 10.000 schema thực tế. BoundaryML còn đi xa hơn, lập luận rằng đầu ra có cấu trúc thực sự làm giảm khả năng suy luận của mô hình. Sự đồng thuận: **không nên dùng Function Calling với các schema phức tạp.**

Chúng tôi không thể từ bỏ. Nếu không có đầu ra có cấu trúc, việc xác minh bằng máy móc là không thể; nếu không có xác minh, các vòng lặp phản hồi là không thể; nếu không có vòng lặp phản hồi, việc đảm bảo là không thể.

Vì vậy, chúng tôi đã xây dựng Function Calling Harness. Kiến trúc 3 tầng của Typia là cốt lõi của nó:

Cả ba tầng đều được tự động tạo bởi trình biên dịch của Typia từ các định nghĩa kiểu TypeScript. Các nhà phát triển chỉ cần định nghĩa các kiểu TypeScript—schema Function Calling, logic phục hồi parse(), trình kiểm tra validate() và trình tạo phản hồi LlmJson.stringify() đều được suy ra từ cùng một kiểu. **Một kiểu duy nhất quản lý schema, phân tích cú pháp, xác thực và phản hồi đồng thời.**

parse() — Phục Hồi JSON Bị Hỏng

LLM không phải là trình tạo JSON. Chúng gói đầu ra trong các khối mã markdown, thêm tiền tố “I’d be happy to help!”, để các dấu ngoặc không đóng, bỏ qua dấu nháy trên khóa và viết tru thay vì true. Dòng Qwen 3.5 còn tệ hơn—nó tuần tự hóa kép mọi trường union type với **xác suất 100%**. Một phản hồi sản xuất thực tế chứa 7 vấn đề đồng thời:

import { dedent } from "@typia/utils";
import typia, { ILlmApplication, ILlmFunction, tags } from "typia";

const app: ILlmApplication = typia.llm.application<OrderService>();
const func: ILlmFunction = app.functions[0];

// LLM sometimes returns malformed JSON with wrong types
const llmOutput = dedent`
  > LLM sometimes returns some prefix text with markdown JSON code block.

  I'd be happy to help you with your order! 😊

  \`\`\`json
  {
    "order": {
      "payment": "{\\"type\\":\\"card\\",\\"cardNumber\\":\\"1234-5678", // unclosed string & bracket
      "product": {
        name: "Laptop", // unquoted key
        price: "1299.99", // wrong type (string instead of number)
        quantity: 2, // trailing comma
      },
      "customer": {
        // incomplete keyword + unclosed brackets
        "name": "John Doe",
        "email": "john@example.com",
        vip: tru
  \`\`\` `;

const result = func.parse(llmOutput);
if (result.success) console.log(result);

interface IOrder {
  payment: IPayment;
  product: {
    name: string;
    price: number & tags.Minimum<0>;
    quantity: number & tags.Type<"uint32">;
  };
  customer: {
    name: string;
    email: string & tags.Format<"email">;
    vip: boolean;
  };
}

type IPayment =
  | { type: "card"; cardNumber: string }
  | { type: "bank"; accountNumber: string };

declare class OrderService {
  /**
   * Create a new order.
   *
   * @param props Order properties
   */
  createOrder(props: { order: IOrder }): { id: string };
}

Một lệnh gọi duy nhất đến func.parse() phục hồi tất cả 7 vấn đề:

• **Khối markdown & lời nói đầu:** đã được loại bỏ.
• **Chuỗi & dấu ngoặc không đóng** ("1234-5678): tự động hoàn thành.
• **Khóa không có dấu nháy** (name:): được chấp nhận.
• **Dấu phẩy thừa** (quantity: 2,): bị bỏ qua.
• **Từ khóa không hoàn chỉnh** (tru): được hoàn thành thành true.
• **Kiểu sai** ("1299.99"): được chuyển đổi thành 1299.99 theo schema.
• **Tuần tự hóa kép** ("{\"type\":\"card\"...): được khôi phục đệ quy thành đối tượng.

validate() + LlmJson.stringify() — Phản Hồi Chính Xác

Ngay cả sau khi phân tích cú pháp, các giá trị tự thân cũng có thể sai. Giá âm, chuỗi không phải email, số thập phân được mong đợi là số nguyên. Khi validate() phát hiện vi phạm schema, LlmJson.stringify() tạo ra các đánh dấu lỗi // ❌ nội tuyến trên đầu JSON gốc của LLM:

{
  "order": {
    "payment": {
      "type": "card",
      "cardNumber": 12345678 // ❌ [{"path":"$input.order.payment.cardNumber","expected":"string"}]
    },
    "product": {
      "name": "Laptop",
      "price": -100, // ❌ [{"path":"$input.order.product.price","expected":"number & Minimum<0>"}]
      "quantity": 2.5 // ❌ [{"path":"$input.order.product.quantity","expected":"number & Type<\"uint32\">"}]
    },
    "customer": {
      "name": "John Doe",
      "email": "invalid-email", // ❌ [{"path":"$input.order.customer.email","expected":"string & Format<\"email\">"}]
      "vip": "yes" // ❌ [{"path":"$input.order.customer.vip","expected":"boolean"}]
    }
  }
}

LLM chỉ cần sửa các lỗi được đánh dấu trên đầu ra của chính nó—không cần viết lại mọi thứ, chỉ cần sửa 5 trường được gắn cờ. **Phản hồi chính xác, có cấu trúc và có thể hành động ngay lập tức.**

Vòng lặp này là thứ biến 6.75% thành 100%. Hơn nữa, trình biên dịch 4 giai đoạn của AutoBE (Database -> OpenAPI -> Test -> TypeScript) thêm các vòng lặp tự sửa lỗi cấp hệ thống. **Xác thực kép ở cấp độ Function Calling và cấp độ trình biên dịch** là điều thúc đẩy tỷ lệ biên dịch thành công 100%.

Bối Cảnh Phát Triển Của AutoBE: Hành Trình Từ Đơn Giản Đến Phức Tạp

Trước khi phân tích sâu hơn Claude Code, điều quan trọng là phải hiểu bối cảnh phát triển của AutoBE. AutoBE chưa bao giờ chú ý nhiều đến việc điều phối tác nhân. **Điều này là có chủ ý.**

Chúng tôi giữ quy trình làm việc ở dạng đơn giản nhất có thể: một luồng thác nước một chiều, một vòng tự đánh giá của AI và một lần tạo mã. Chúng tôi cũng cố ý **cấm các mô hình lớn**, chạy các thí nghiệm lặp đi lặp lại với các mô hình nhỏ (qwen3-30b-a3b, 3B hoạt động). Có ba lý do cho cách tiếp cận này:

Giữ Đơn Giản Có Chủ Ý

Tính Ổn Định

Chúng tôi cần đo lường tỷ lệ thành công của mỗi giai đoạn trong pipeline một cách độc lập. Việc điều phối phức tạp khiến việc xác định giai đoạn nào bị lỗi trở nên khó khăn. Trong một pipeline đơn giản, “FK bị hỏng ở giai đoạn Database” là rõ ràng. Trong điều phối phức tạp, nó trở thành “có gì đó sai ở đâu đó.”

Khả Năng Gỡ Lỗi

Càng nhiều giai đoạn AI tự động can thiệp, việc theo dõi nguyên nhân thất bại càng khó khăn theo cấp số nhân. Khi Agent A sửa một cái gì đó, Agent B lại chạm vào nó, và Agent C sửa đổi kết quả đó—nguyên nhân gốc rễ bị chôn vùi.

Ngăn Ngừa Che Giấu Điểm Yếu

AI thông minh và quy trình làm việc tinh vi **che giấu các lỗ hổng của hệ thống**. Nếu giai đoạn Database tạo ra một schema bị lỗi nhưng AI của giai đoạn Interface tiếp theo lặng lẽ bù đắp, bạn sẽ không bao giờ phát hiện ra điểm yếu của giai đoạn Database. Các lỗ hổng được phơi bày bởi các mô hình nhỏ cũng tồn tại trong các mô hình lớn—chúng chỉ xuất hiện ít thường xuyên hơn. “Ít thường xuyên hơn” trở thành “thỉnh thoảng” trong sản xuất, và “thỉnh thoảng” trở thành một sự cố ngừng hoạt động.

Vì vậy, chúng tôi cố tình—với các mô hình nhỏ, trong một pipeline đơn giản, với sự can thiệp tối thiểu của AI—chỉ thắt chặt việc xác thực ở mỗi giai đoạn.

Phá Vỡ 100% Và Xây Dựng Lại

Chúng tôi đã từng đạt được tỷ lệ thành công biên dịch + chạy 100%. Sau đó, chúng tôi cố tình phá vỡ nó để xây dựng lại ở một cấp độ chất lượng cao hơn.

Chia Để Trị

Mục tiêu đầu tiên của AutoBE rất đơn giản: tạo ra mỗi hàm API một cách độc lập. Không tái sử dụng mã, không phụ thuộc giữa các hàm, mỗi hàm tự chứa. Nếu 10 hàm truy vấn cùng một bảng, tất cả 10 hàm đều chứa cùng một truy vấn trùng lặp.

Bạn không thể chạy trước khi đi. Trước tiên, chúng tôi cần chứng minh, ở dạng đơn giản nhất có thể, rằng Function Calling Harness hoạt động, rằng vòng lặp phản hồi của trình biên dịch đạt được khả năng tự sửa lỗi, và rằng 100% có thể đạt được ngay cả với các mô hình nhỏ.

Và chúng tôi đã chứng minh được điều đó. 100% biên dịch, 100% chạy. Ngay cả với các mô hình nhỏ. **Nền tảng hoạt động.**

Đầu Ra Không Phải Là Phần Mềm

Sau khi đạt 100% biên dịch và chạy, chúng tôi xem xét đầu ra. Nó biên dịch và chạy—nhưng nó **không phải là phần mềm có thể bảo trì.** Thêm một cột vào một bảng có nghĩa là phải tạo lại tất cả 10 hàm liên quan. Thay đổi yêu cầu có nghĩa là phải xây dựng lại từ đầu. Nếu không tái sử dụng mã, đầu ra có thể được tạo ra nhưng không thể phát triển.

Nhiệm vụ tiếp theo đã rõ ràng: chuyển sang một **cấu trúc cho phép tái sử dụng mã**—nơi các hàm gọi các hàm khác, logic dùng chung hội tụ ở một nơi và các thay đổi yêu cầu chỉ cần sửa đổi những gì đã thay đổi.

Phá Vỡ Nó

Vì vậy, chúng tôi đã phá vỡ 100%.

Việc giới thiệu các phụ thuộc giữa các module đã khiến tỷ lệ thành công **giảm mạnh xuống 40%**. Các vấn đề không tồn tại với các hàm độc lập đã bùng phát cùng một lúc—khi các hàm gọi nhau, lỗi của một hàm sẽ phá vỡ hàm khác. Các kiểu trả về không khớp, các import bị rối, thứ tự phụ thuộc bị phá vỡ. Một hình ảnh thu nhỏ của **hiệu ứng cộng gộp** từ Phần 2.2—khi 100 module phụ thuộc vào nhau, tỷ lệ thành công 95% của mỗi module hội tụ về 0% ở cấp độ hệ thống.

Từ 100% xuống 40%. Mất hàng tháng. Chúng tôi tăng cường trình biên dịch, tinh chỉnh các vòng lặp sửa lỗi và cải thiện Harness.

Chúng tôi đã đạt lại 100% biên dịch. 100% thời gian chạy vẫn đang được khôi phục.

Đã Đến Lúc Trở Nên Tinh Vi Hơn

Tại thời điểm này, chúng tôi đã hoàn toàn đạt được 100% biên dịch. 100% thời gian chạy vẫn đang được tiến hành.

Đây là lúc chúng tôi tuyên bố:

“Với 100% biên dịch được đảm bảo làm nền tảng, đã đến lúc chúng ta bắt đầu trở nên tinh vi hơn.”

Giới thiệu các vòng lặp tự đánh giá của tác nhân. Tinh chỉnh các lời nhắc. Thêm sự tinh vi vào việc điều phối. **Cho dù bạn tạo ra một quy trình làm việc tinh vi đến đâu mà không có nền tảng xác minh, nó cũng chẳng khác gì một trò tung xúc xắc phức tạp.** Đặt nền tảng xác minh trước, sau đó xây dựng quy trình làm việc lên trên—chúng tôi tin rằng đây là thứ tự đúng đắn.

Để làm được điều đó, chúng tôi cần **nghiên cứu nghiêm túc cách các tác nhân AI khác thiết kế cơ chế điều phối của họ.**

Đó chính xác là khi mã nguồn Claude Code bị rò rỉ.

Phân Biệt Các Thế Hệ Agent AI: Claude Code (2.0) vs. AutoBE (3.0)

Trước khi so sánh, hãy làm rõ một điều: hai dự án này đang giải quyết **các vấn đề khác nhau về cơ bản**.

Claude Code — Thế Hệ 2: Nhà Phát Triển Cấp Cao Ngồi Cạnh Bạn

Dòng đầu tiên của lời nhắc hệ thống:

"You are an interactive agent that helps users
with software engineering tasks."

“giúp người dùng”—con người dẫn dắt, AI hỗ trợ. Khi người dùng yêu cầu đọc một tệp, nó đọc. Khi được yêu cầu sửa mã, nó sửa. Với hơn 40 công cụ đa năng và một vòng lặp while(true), LLM tự động chọn công cụ ở mỗi lượt.

Sức mạnh là tính linh hoạt. Bất kỳ ngôn ngữ, bất kỳ framework nào—khả năng đọc tệp, hiểu ngữ cảnh và sửa chính xác những gì cần thiết là tốt nhất trong lớp. Một ngày của nhà phát triển là một cuộc chiến đa ngôn ngữ: gỡ lỗi Python, tái cấu trúc Go, sửa Terraform. Xử lý tất cả những điều này trong một phiên duy nhất không phải là sự thỏa hiệp; đó chính xác là những gì hầu hết các nhà phát triển cần nhất trong hầu hết thời gian.

Kỹ thuật tạo lời nhắc (prompt engineering), thiết kế quy trình làm việc tác nhân (agent workflow design) và triển khai công cụ (tool implementations) đều xuất sắc về mặt kỹ thuật. Bảy đường dẫn phục hồi, nén ngữ cảnh 4 tầng, thực thi công cụ suy đoán trong quá trình streaming, hơn 400KB mã bảo mật BashTool. Đây là đỉnh cao của phát triển tác nhân AI.

AutoBE — Thế Hệ 3: Nhà Máy Backend Tự Đủ

Cốt lõi của lời nhắc hệ thống:

"You are a professional backend engineer—not an assistant"

“không phải là một trợ lý”—AI dẫn dắt, các trình biên dịch xác minh. Người dùng chỉ cần nêu yêu cầu. Phần còn lại được thực thi tự động bởi 42 tác nhân AI chuyên biệt trên một pipeline 5 giai đoạn.

Cốt lõi là kiến trúc **biểu mẫu + trình biên dịch**. Vì LLM điền vào các biểu mẫu schema thay vì văn bản tự do, phương sai được loại bỏ; vì các trình biên dịch xác thực các biểu mẫu, tỷ lệ thành công trên mỗi đơn vị hội tụ về 100%. **1.0^400 = 1.0**—hiệu ứng cộng gộp bị đảo ngược. Không cần đánh giá của con người. Máy móc cung cấp sự đảm bảo.

Điều Gì Tách Biệt Các Thế Hệ

Tác nhân xác minh khác nhau:

|                      | Thế Hệ 2                   | Thế Hệ 3                     |
| ---                  | ---                        | ---                          |
| <strong>Đánh giá tính nhất quán</strong> | Con người                   | Máy móc                       |
| <strong>Phát hiện lỗi</strong>       | Người dùng phát hiện      | Trình biên dịch phát hiện    |
| <strong>Vòng lặp sửa lỗi</strong>     | Người dùng hướng dẫn       | Tự động lặp lại              |
| <strong>Phương pháp ràng buộc</strong>  | Cấm đoán qua lời nhắc (voi hồng) | Vắng mặt qua schema (loại bỏ tùy chọn) |
| <strong>Độ tin cậy</strong>         | 0.95^n -> 0                | 1.0^n = 1.0                  |
| <strong>Tính nhất quán</strong>      | Phụ thuộc mô hình (Claude != GPT != Qwen) | Độc lập mô hình (cùng đích đến) |
| <strong>Ví dụ điển hình</strong>   | Claude Code, Cursor        | AutoBE                       |

Claude Code là một **trợ lý tuyệt vời**. Điều hướng tệp, gỡ lỗi, tái cấu trúc—như một nhà phát triển cấp cao ngồi cạnh bạn, nó là tốt nhất trong lớp. Nhưng “trợ lý” và “người xây dựng” là những vấn đề khác nhau. Để **xây dựng một backend với 50 bảng và 400 API từ đầu đến cuối**—để đảm bảo **từ 80 đến 100**—tác nhân xác minh không thể là con người. Nó phải là máy móc.

Claude Code đại diện cho đỉnh cao của thế hệ thứ 2: lời nhắc và quy trình làm việc tác nhân được tinh chỉnh đến cực điểm, đạt được thành tựu cao nhất có thể với cách tiếp cận do con người dẫn dắt. Thế hệ thứ 3 đi theo hướng ngược lại—thông qua Function Calling Harness và các trình biên dịch AI-native, nó hy sinh tính tổng quát để nhắm mục tiêu 100% thành công trong một lĩnh vực chuyên biệt. Đây không phải là về sự vượt trội; đó là về hướng đi. Sự khác biệt cốt lõi: **ai đảm bảo tính nhất quán của đầu ra được tạo ra.**

Những Bài Học Rút Ra Từ Việc Phân Tích Claude Code

Vòng Lặp Agent: while(true) so với Thác Nước

Trái Tim Của Claude Code

Vòng lặp while(true) 1.730 dòng trong query.ts:

while(true) {
    Giai đoạn 1: Chuẩn bị ngữ cảnh (đếm token, nén)
    Giai đoạn 2: Streaming API (phát hiện gọi công cụ)
    Giai đoạn 3: Phục hồi (7 điểm tiếp tục)
    Giai đoạn 4: Thực thi công cụ (kiểm soát đồng thời)
    Giai đoạn 5: Quyết định tiếp tục/thoát
}

Bảy điểm continue mỗi điểm đại diện cho một đường dẫn phục hồi khác nhau:

| Điểm tiếp tục         | Kích hoạt                    | Phục hồi                      |
| ---                   | ---                          | ---                           |
| `collapse_drain_retry`| 413 Prompt quá dài           | Xả nén theo giai đoạn         |
| `reactive_compact_retry`| Vẫn 413 sau khi xả           | Nén tự động hoàn toàn         |
| `max_output_tokens_escalate`| Giới hạn đầu ra 8k        | Nâng cấp lên 64k              |
| `max_output_tokens_recovery`| Vượt quá 64k              | Chèn "tiếp tục trực tiếp"     |
| `streaming_fallback`  | Lỗi streaming                | Thử lại hoàn toàn             |
| `stop_hook_blocking`  | Lỗi hook                     | Thêm lỗi vào cuộc trò chuyện |
| `token_budget_continuation`| Trong ngân sách token     | Tự động tiếp tục             |

Sức mạnh của vòng lặp này là **tính linh hoạt**. “Đọc một tệp, sửa đổi nó, chạy kiểm thử”—bất kể sự kết hợp nào, LLM đều tìm ra luồng.

Pipeline Xác Định Của AutoBE

Hoàn toàn ngược lại. 42 tác nhân AI chuyên biệt thực thi theo một thứ tự được mã hóa cứng. Chỉ riêng giai đoạn Realize:

orchestrateRealize()
  |-- orchestrateRealizeCollector (DB query functions)
  |   |-- Plan -> Write -> Validate
  |   +-- On failure -> CorrectCasting / CorrectOverall
  |-- orchestrateRealizeTransformer (result transformation functions)
  |-- orchestrateRealizeAuthorizationWrite (auth logic)
  |-- orchestrateRealizeOperation (business logic)
  |   +-- Correction loop: TypeScript compile -> diagnostics -> regenerate
  +-- compileRealizeFiles (final validation)

Những gì chạy song song, bao nhiêu cùng một lúc, điều gì xảy ra khi thất bại—tất cả đều được xác định trong mã. Dễ đoán, nhưng kém linh hoạt.

So Sánh

|                   | Claude Code (Thế hệ 2)           | AutoBE (Thế hệ 3)                  |
| ---               | ---                              | ---                                |
| <strong>Kiến trúc</strong>           | `while(true)` + lựa chọn công cụ tự do | Pipeline 5 giai đoạn + 42 tác nhân chuyên biệt |
| <strong>Quyết định công cụ</strong>    | LLM tự động quyết định mỗi lượt     | Mã quyết định trước               |
| <strong>Vòng đời tác nhân</strong>   | Duy trì cho toàn bộ phiên       | Được tạo theo tác vụ -> loại bỏ (MicroAgentica) |
| <strong>Thích hợp nhất cho</strong> | Khám phá mở, gỡ lỗi              | Tạo mã có cấu trúc                |

Quản Lý Ngữ Cảnh: Nén Hậu Kỳ so với Chọn Lọc Trước

Claude Code — Nén 4 Tầng

Khi các cuộc trò chuyện tăng lên, nó nén:

1. Snip—Loại bỏ tin nhắn trước các điểm kiểm tra.
2. Microcompact—Xóa kết quả công cụ lỗi thời phía máy chủ thông qua cache_edits của API. Không chạm vào tin nhắn cục bộ, nên bộ nhớ đệm không bị vô hiệu hóa.
3. Context Collapse—Chiếu (projection) theo thời gian đọc (cam kết nén theo giai đoạn ở 90%, chặn ở 95%).
4. Autocompact—Yêu cầu LLM tóm tắt cuộc trò chuyện (khi vượt quá 167k token). Ngắt mạch sau 3 lần thất bại liên tiếp.

Ngay cả trong lời nhắc hệ thống, các phần tĩnh và động cũng được phân tách bằng SYSTEM_PROMPT_DYNAMIC_BOUNDARY:

const [staticPart, dynamicPart] = systemPrompt.split(
  SYSTEM_PROMPT_DYNAMIC_BOUNDARY
)
// staticPart -> cache_control: { scope: 'global' } (cross-user cache)
// dynamicPart -> cache_control: { scope: 'session' }

Dấu phân cách duy nhất này giảm đáng kể chi phí bộ nhớ đệm lời nhắc. Không có bộ nhớ đệm, một phiên Opus dài tiêu tốn 50-100 đô la; với bộ nhớ đệm, nó giảm xuống 10-19 đô la—giảm chi phí khoảng 80%.

AutoBE — 48 History Transformers

AutoBE không nén—nó **chuyển đổi**. 48 History Transformers tập hợp **chính xác ngữ cảnh mà mỗi bộ điều phối cần:**

// History Transformer for Realize Write
const histories = [
  { type: "systemMessage", text: REALIZE_OPERATION_WRITE,
    _cache: { type: "ephemeral" } },           // system prompt (cached)
  { type: "userMessage", text: formatDatabaseSchemas(state),
    _cache: { type: "ephemeral" } },           // only relevant DB schemas (cached)
  { type: "userMessage", text: formatOperation(operation) },
  { type: "userMessage", text: formatCollectors(collectors) },
];
// 180KB toàn bộ ngữ cảnh -> 8KB ngữ cảnh chính xác (giảm 95%)

Điều này có thể thực hiện được vì các tác nhân có thể loại bỏ. Không cần nén các cuộc trò chuyện trước—chỉ cần cung cấp cho mỗi tác nhân mới chính xác những gì nó cần.

Mẫu executeCachedBatch cũng tối đa hóa hiệu quả bộ nhớ đệm: tác vụ đầu tiên thực thi tuần tự để thiết lập bộ nhớ đệm, sau đó phần còn lại chạy song song với tỷ lệ truy cập bộ nhớ đệm trên 90%. Khi triển khai 40 API, điều này giảm chi phí token khoảng 88%.

So Sánh

|                   | Claude Code (Thế hệ 2)           | AutoBE (Thế hệ 3)                  |
| ---               | ---                              | ---                                |
| <strong>Chiến lược</strong>          | Thu nhỏ những gì tồn tại (nén hậu kỳ) | Bắt đầu với ít hơn (chọn lọc trước)    |
| <strong>Chi phí tăng trưởng</strong>   | O(N) ~ O(N^2)                    | O(1)—độc lập với độ dài cuộc trò chuyện |
| <strong>Mất mát thông tin</strong> | Không thể tránh khỏi khi tóm tắt    | Không có (chỉ những gì cần thiết là có) |
| <strong>Bộ nhớ đệm</strong>        | Tách `DYNAMIC_BOUNDARY`          | Mẫu `executeCachedBatch`             |

An Toàn: 23 Kiểm Tra Bảo Mật so với Cổng Trình Biên Dịch

Sự so sánh này bộc lộ rõ ràng nhất sự khác biệt về mục đích cốt lõi giữa hai dự án.

Claude Code — Bảo Vệ Hệ Thống Của Người Dùng

Claude Code **thực thi các lệnh trực tiếp trên máy tính của người dùng**. Rủi ro là “LLM chạy rm -rf /.” Do đó có nhiều lớp phòng thủ:

Lớp 1: Phân tích cú pháp AST bằng Tree-sitter cho phân tích ngữ nghĩa các lệnh shell
Lớp 2: Toàn bộ lịch sử cuộc trò chuyện được gửi đến LLM để đánh giá an toàn theo ngữ cảnh
Lớp 3: Sandbox cấp hệ điều hành (macOS seatbelt, Linux bwrap + seccomp)
Lớp 4: Công cụ quy tắc quyền từ 8 nguồn
Lớp 5: Phát hiện mẫu hủy hoại (rm -rf, DROP TABLE, terraform destroy)
Lớp 6: Ngân sách kích thước kết quả công cụ (lưu trữ đĩa khi vượt quá 50KB)

Hơn **400KB** mã bảo mật liên quan đến BashTool, với 23 danh mục kiểm tra bảo mật phân tích ngữ nghĩa của các lệnh shell. 400KB mã bảo mật cho một công cụ duy nhất là một khoản đầu tư kỹ thuật nghiêm túc.

AutoBE — Bảo Vệ Tính Nhất Quán Đầu Ra

Rủi ro của AutoBE khác: “LLM tạo mã không chính xác.” Nó không chạm vào hệ thống tệp thực tế—nó hoạt động trên một hệ thống tệp ảo (Record<string, string>):

Cổng 1: Xác thực schema Typia (đầu ra Function Calling)
Cổng 2: Trình biên dịch cơ sở dữ liệu (tính toàn vẹn FK, tham chiếu vòng tròn, từ khóa dành riêng)
Cổng 3: Trình biên dịch giao diện OpenAPI (tính nhất quán đặc tả, kiểm tra chéo DB)
Cổng 4: Trình biên dịch kiểm thử (xác thực biểu thức, tính nhất quán kịch bản)
Cổng 5: Trình biên dịch Hybrid (trình biên dịch TypeScript + AST một phần)

Xây dựng tường lửa so với xây dựng một cấu trúc nơi lửa không thể bắt đầu. Các mô hình đe dọa khác nhau đòi hỏi các chiến lược phòng thủ khác nhau.

Thực Thi Chính Sách Thông Qua Kiểu Dữ Liệu

Một đoạn mã khiến chúng tôi dừng lại giữa chừng:

export type AnalyticsMetadata_I_VERIFIED_THIS_IS_NOT_CODE_OR_FILEPATHS = never

**Tên kiểu dữ liệu tự nó là một tuyên bố chính sách.** Khi ghi nhật ký sự kiện, bạn phải ép kiểu sang kiểu này, và nhà phát triển thấy tên: “Tôi đã xác minh rằng đây không phải là mã hoặc đường dẫn tệp.” Một bình luận sẽ bị bỏ qua, nhưng tên kiểu dữ liệu sống trong luồng biên dịch.

Đây là cùng tinh thần với nguyên tắc cốt lõi của AutoBE—**ràng buộc thông qua sự vắng mặt**:

Lời nhắc: "Không dùng varchar, text, bigint" -> LLM thực sự nghĩ về chúng
Schema: type: "boolean" | "int" | "double" | "string" | "uri" | "uuid" | "datetime"
-> varchar không tồn tại như một tùy chọn -> không thể tạo ra về mặt vật lý

Thay vì nói “đừng làm điều đó,” hãy làm cho nó không thể. Các cách tiếp cận khác nhau, nhưng điểm xuất phát là như nhau—**giảm lựa chọn.**

Chế Độ Điều Phối — Mẫu Trưởng Nhóm Con Người

Quy Trình Làm Việc

Chế độ Điều phối của Claude Code chỉ định LLM làm trưởng nhóm:

Nghiên cứu (các worker song song) -> Tổng hợp (bộ điều phối xử lý trực tiếp) -> Triển khai -> Xác minh

Kết quả của các worker đến dưới dạng XML:

<task-notification>
  <task-id>agent-a1b2c3</task-id>
  <status>completed</status>
  <result>Agent's final text response</result>
</task-notification>

LLM điều phối phân tích điều này và quyết định bước tiếp theo. **Điều gì cần song song hóa, chạy bao nhiêu—LLM quyết định mọi thứ thông qua suy luận.**

Một Nguyên Tắc Thiết Kế Đáng Kính Nể

Các mẫu bị cấm rõ ràng trong lời nhắc:

// Sai: "Dựa trên những phát hiện của bạn, sửa lỗi xác thực"
// Đúng: "Sửa lỗi con trỏ null trong src/auth/validate.ts:42.
//   Trường người dùng trên Session không được định nghĩa khi phiên hết hạn."

“Lời nhắc gửi cho các worker phải tự chứa.” Đây là cùng một hiểu biết sâu sắc đằng sau các History Transformer của AutoBE, được khám phá độc lập thông qua một con đường khác.

Trong khi executeCachedBatch của AutoBE mã hóa cứng “cái gì cần song song hóa” vào mã, Coordinator ủy quyền ngay cả quyết định đó cho LLM. Thích ứng nhưng không thể đoán trước so với xác định nhưng kém linh hoạt—một hình ảnh thu nhỏ của sự phân chia giữa thế hệ thứ 2 và thứ 3.

So Sánh Toàn Diện: Claude Code Và AutoBE Qua Lăng Kính Kỹ Thuật

| Khía cạnh             | Claude Code (Thế hệ 2)           | AutoBE (Thế hệ 3)                  |
| ---                  | ---                              | ---                                |
| <strong>Định nghĩa một dòng</strong>   | Nhà phát triển cấp cao ngồi cạnh bạn | Một nhà máy backend tự túc          |
| <strong>Kiến trúc tác nhân</strong>   | Một tác nhân, `while(true)`      | 42 tác nhân AI chuyên biệt         |
| <strong>Chọn công cụ</strong>       | LLM tự động chọn từ hơn 40 công cụ | Mã quyết định trước               |
| <strong>Vòng đời tác nhân</strong>   | Duy trì cho toàn bộ phiên       | Được tạo theo tác vụ -> loại bỏ   |
| <strong>Quản lý ngữ cảnh</strong>    | Nén hậu kỳ 4 tầng                 | 48 History Transformers, chọn lọc trước |
| <strong>Xác thực</strong>           | Chẩn đoán LSP + xác nhận người dùng | Trình biên dịch 4 giai đoạn + tự phục hồi (tối đa 4 vòng) |
| <strong>An toàn</strong>             | 23 kiểm tra bảo mật + phân loại ML + sandbox | 5 cổng trình biên dịch            |
| <strong>Thực thi song song</strong> | Phán đoán của LLM (Coordinator)     | `executeCachedBatch` (xác định)  |
| <strong>Chiến lược bộ đệm</strong>  | Tách `DYNAMIC_BOUNDARY`          | Tối ưu hóa theo thứ tự tin nhắn   |
| <strong>Độc lập mô hình</strong>   | Phụ thuộc API Claude               | Hoạt động với bất kỳ LLM nào      |
| <strong>Đơn vị đầu ra</strong>      | Chỉnh sửa tệp, lệnh shell        | Ứng dụng backend hoàn chỉnh        |
| <strong>Tính tổng quát</strong>     | Bất kỳ dự án, bất kỳ ngôn ngữ      | Chỉ TypeScript + NestJS            |
| <strong>Hệ sinh thái</strong>        | MCP + plugin + cầu nối IDE       | Mở rộng chuỗi trình biên dịch      |
| <strong>Kích thước codebase</strong> | 512.000 dòng, 1.900 tệp        | 153.000 dòng, 1.400 tệp        |

Đồng Thuận Trong Triết Lý Thiết Kế Và Những Phát Hiện Độc Đáo

Cùng Một Con Đường, Khung Cảnh Khác Biệt

Điều đáng kinh ngạc nhất khi đọc mã nguồn Claude Code là phát hiện ra rằng, mặc dù được xây dựng hoàn toàn độc lập, chúng tôi đã đi đến **cùng một kết luận** trên một số mặt.

“Làm Cho Nó Không Thể Về Mặt Cấu Trúc”

Kiểu AnalyticsMetadata_I_VERIFIED_THIS_IS_NOT_CODE_OR_FILEPATHS từ Phần 5.4 và hạn chế kiểu 7 trường của chúng tôi. Các cách tiếp cận khác nhau, cùng một điểm xuất phát—**giảm lựa chọn mạnh hơn là cấm đoán.** Sự tiến hóa hội tụ từ phát triển độc lập cho thấy nguyên tắc này là mạnh mẽ.

“Cung Cấp Ngữ Cảnh Tự Chứa Cho Các Worker”

Nguyên tắc tự chứa từ Chế độ Điều phối (Phần 5.5) và những gì 48 History Transformer của chúng tôi làm là cùng một điều. Dù là worker hay orchestrator, nó phải có khả năng hoàn thành nhiệm vụ của mình chỉ với ngữ cảnh mà nó nhận được.

“Cache Tiền Tố, Chỉ Thay Đổi Hậu Tố”

SYSTEM_PROMPT_DYNAMIC_BOUNDARY từ Phần 5.2 và executeCachedBatch của chúng tôi giải quyết cùng một vấn đề. Cách tiếp cận của họ là khai báo ranh giới bằng một **dấu hiệu rõ ràng** thì sạch sẽ hơn—chúng tôi đã bắt đầu áp dụng nó.

Chi Tiết Kỹ Thuật Đáng Chú Ý

StreamingToolExecutor — Thực Thi Công Cụ Suy Đoán Trong Quá Trình Streaming

Hầu hết các tác nhân chờ phản hồi đầy đủ của mô hình trước khi thực thi công cụ. Claude Code phát hiện các lệnh gọi công cụ **trong khi mô hình vẫn đang streaming** và bắt đầu thực thi ngay lập tức. Các công cụ không có tác dụng phụ như đọc tệp có kết quả sẵn sàng trước khi phản hồi kết thúc. Sức bền kỹ thuật thuần túy. Các tác nhân dùng một lần của chúng tôi ít nhạy cảm hơn với độ trễ phiên, nhưng đây là một tối ưu hóa thanh lịch cho các phiên chạy dài.

cache_edits — Xóa Cache Phía Máy Chủ Không Hủy Hoại

Khi các cuộc trò chuyện tăng lên, các kết quả công cụ cũ cần được loại bỏ. Thông thường, việc sửa đổi các tin nhắn cục bộ sẽ làm mất hiệu lực bộ đệm. Claude Code sử dụng cache_edits của API Anthropic để xóa **chỉ trên máy chủ**, giữ nguyên các tin nhắn cục bộ—giảm ngữ cảnh mà không làm mất hiệu lực bộ đệm.

Mặc Định “Đóng Lỗi” Của buildTool()

Khi tạo một công cụ mới, các mặc định là isConcurrencySafe: false, isReadOnly: false—một thiết kế **bắt đầu ở mức hạn chế tối đa và nới lỏng rõ ràng**. Nguyên tắc: “nguy hiểm cho đến khi được chứng minh là an toàn.” Cùng triết lý với các cổng trình biên dịch của chúng tôi, nhưng việc thấy nó được triển khai sạch sẽ như vậy ở cấp độ đăng ký công cụ rất đáng để học hỏi.

Tính Đặc Hiệu Của Mô Hình Đe Dọa

Mỗi trong số 23 danh mục kiểm tra bảo mật có một câu trả lời rõ ràng cho “điều này ngăn chặn điều gì?” Tiêm ký tự đặc biệt của shell, thao tác biến IFS, truy cập môi trường tiến trình, ngụy trang khoảng trắng Unicode, chèn ký tự điều khiển—mỗi danh mục giải quyết một mối đe dọa cụ thể, có tên. Mức độ tài liệu này đã truyền cảm hứng cho chúng tôi bắt đầu lập danh mục chính xác lỗ hổng nào mà mỗi trình biên dịch 5 cổng của chúng tôi ngăn chặn.

“Chiếu Thời Gian Đọc” Của Context Collapse

Khi ngữ cảnh vượt quá 90%, nó nén—nhưng **không sửa đổi lịch sử gốc**. Thay vào đó, nó cung cấp một chế độ xem nén chỉ ở thời gian đọc, một cách tiếp cận “chiếu”. Vì bản gốc được bảo toàn, bạn luôn có thể quay lại. Các History Transformer của chúng tôi cũng giữ nguyên trạng thái gốc, nhưng việc hình thức hóa rõ ràng điều này như một mẫu chiếu là một sự trừu tượng hữu ích.

Thực Thi Suy Đoán

Khám phá đáng ngạc nhiên nhất trong mã nguồn. Khi người dùng không hoạt động, Claude Code **thực thi dự đoán** những gì nó nghĩ người dùng sẽ làm tiếp theo—không trên hệ thống tệp thực tế, mà trong một **lớp phủ copy-on-write**:

// Copy-on-write: sao chép bản gốc vào lớp phủ, chuyển hướng tất cả các ghi vào lớp phủ
if (!writtenPathsRef.current.has(rel)) {
  await copyFile(join(cwd, rel), join(overlayPath, rel))
  writtenPathsRef.current.add(rel)
}

Nếu người dùng chấp nhận, lớp phủ được sao chép vào chính; nếu bị từ chối, lớp phủ bị xóa. **Dự đoán nhánh CPU được áp dụng cho một tác nhân mã hóa AI.** Nếu dự đoán đúng, độ trễ biến mất; nếu sai, chi phí duy nhất là tính toán—cơ sở mã thực tế không bao giờ bị chạm. Dự đoán nhánh cho các tác nhân AI là một cấp độ tư duy hệ thống mà chúng tôi chưa từng thấy được áp dụng cho lĩnh vực này.

`` Vùng Nháp Ẩn

Khi tóm tắt các cuộc trò chuyện, LLM trước tiên sắp xếp suy nghĩ của mình bên trong một thẻ ``, cải thiện chất lượng tóm tắt. Sau khi tóm tắt hoàn tất, phần **`` bị loại bỏ**, chỉ còn lại `

formattedSummary = formattedSummary.replace(
  /<analysis>[\s\S]*?<\/analysis>/, ''
)

// @[MODEL LAUNCH]: Tỷ lệ báo cáo sai của Capybara v8 29-30% (v4 là 16.7%)
"If a test fails, say it failed. If you didn't run a verification step, say you didn't.
 Never claim 'all tests passed' when failures are visible in the output."