Codex for Sales: Chạy Logic Kinh Doanh Do AI Tạo Trong Môi Trường Sản Xuất

Khi chủ một spa nói “chúng tôi thêm massage Thái, 200 baht,” năm việc phải xảy ra. Lược đồ dịch vụ phải liệt kê dịch vụ đó. Lược đồ đơn hàng phải tham chiếu đến nó. Công thức định giá phải tính toán được nó. Hàm lên lịch phải đặt chỗ được nó. Hàm xác thực phải kiểm tra được nó.

Các tệp này tạo thành một chuỗi phụ thuộc. Phá vỡ trình tự và hệ thống sẽ thất bại — không phải với lỗi 404, mà là với một mức giá cho một dịch vụ không có trong danh mục.

Hầu hết các nền tảng AI giao toàn bộ tầng này cho một mô hình ngôn ngữ. Mô hình đọc một prompt yêu cầu “cập nhật tất cả các kỹ năng hạ nguồn.” Đôi khi nó làm đúng. Đôi khi nó bỏ qua một bước. Đôi khi nó sắp xếp lại các tệp. Không có rollback. Không có xác thực nào phát hiện ra lỗ hổng cho đến khi khách hàng khiếu nại hóa đơn.

Tại QuotyAI, chúng tôi giải quyết vấn đề này bằng cách giao công việc sáng tạo cho LLM và công việc cấu trúc cho mã xác định. LLM trích xuất ý định — “thêm massage Thái, 200 baht” trở thành dữ liệu có cấu trúc đã định kiểu. Mọi thứ sau đó chạy trên sự điều phối xác định: đồ thị phụ thuộc xác định thứ tự tầng, các tác tử con tạo mã sản xuất từng tệp một cách nguyên tử, đường ống xác thực kiểm tra mọi đầu ra, và người vận hành phê duyệt diff trước khi bất kỳ thay đổi nào đến môi trường sản xuất.

Đây là sáu mẫu thiết kế đã giúp điều này hoạt động trong sản xuất.

“Hệ thống nên làm cho các lỗi cấu trúc trở nên bất khả thi về mặt cấu trúc.”

Lưu ý về phiên bản: Bài viết này đề cập đến kiến trúc trình xây dựng kỹ năng của QuotyAI tính đến tháng 6 năm 2026. Tầng điều phối sử dụng thư viện deepagents để kết hợp tác tử. Tất cả lược đồ Zod sử dụng Zod 4.x. Đồ thị phụ thuộc và định nghĩa kỹ năng được duy trì trong cơ sở hạ tầng của trình xây dựng — không được sao chép vào dữ liệu người thuê.

---

🔗 Vấn Đề Tầng (Cascade Problem)

Logic kinh doanh trong một hệ thống bán hàng không phải là một tệp đơn lẻ. Nó là một đồ thị có hướng không chu trình của các tài nguyên phụ thuộc lẫn nhau:

offerings_schema  →  order_schema  →  pricing_formula
                                    →  scheduling_function
                                    →  validation_function
router, callback, system_prompt  (độc lập)

Thay đổi một nút và mọi nút hạ nguồn phải được tạo lại. Một dịch vụ mới đồng nghĩa với một mục lược đồ mới, một nhánh định giá mới, một khung giờ lên lịch mới và một quy tắc xác thực mới. Bỏ sót bất kỳ mục nào và trợ lý sẽ đưa ra những câu trả lời sai một cách tự tin — báo giá không khớp, đặt chỗ không xác thực được, mức giá không tồn tại.

Vấn đề tầng không chỉ riêng trong bán hàng. Bất kỳ hệ thống AI nào quản lý dữ liệu có cấu trúc phụ thuộc lẫn nhau đều phải đối mặt với nó. Quản lý hàng tồn kho, công cụ quy tắc tuân thủ, nền tảng cấu hình-dưới-dạng-mã — tất cả đều có cùng một ràng buộc cơ bản.

Yêu cầu	Cách tiếp cận LLM ngây thơ	Tầng xác định
Thứ tự cập nhật	Phụ thuộc vào prompt	Sắp xếp tô-pô từ đồ thị phụ thuộc
Xử lý lỗi	Cập nhật một phần	Hủy bỏ nguyên tử khi có bất kỳ lỗi nào
Xác thực	Không có (tin tưởng đầu ra)	Xác thực lược đồ + biên dịch hộp cát
Dấu vết kiểm toán	Rải rác trong nhật ký trò chuyện	Nhật ký sự kiện bất biến cho mỗi lần thăng cấp
Rollback	Khôi phục thủ công	Con trỏ HEAD đến bất kỳ commit nào trước đó

---

📐 Mẫu 1: LLM Cho Ý Nghĩa, Mã Cho Cấu Trúc

Nguyên lý cốt lõi là sự phân tách trách nhiệm chặt chẽ. LLM làm chính xác một việc: chuyển đổi ngôn ngữ tự nhiên thành dữ liệu có cấu trúc đã định kiểu. Mọi thứ sau đó đều là xác định.

"เพิ่มนวดไทย 200 บาท"  →  LLM với đầu ra có cấu trúc
                         →  { name: "Thai Massage", price: 200, category: "massage" }
                         →  Tầng xác định thực thi

Lời gọi LLM sử dụng model.withStructuredOutput() với lược đồ Zod — không phải tạo tự do:

const IntentClassificationSchema = z.object({
  mode: z.enum(['query', 'update']),
  pattern: z.string().nullable(),
  confidence: z.number().min(0).max(1),
});

const result = await model.withStructuredOutput(IntentClassificationSchema)
  .invoke([/* lịch sử hội thoại */]);

Bộ phân loại trả về các đối tượng đã định kiểu: mode, pattern, confidence. Không phân tích chuỗi, không regex, không kỹ thuật prompt thiết kế định dạng đầu ra mong manh.

Khi chế độ là update và độ tin cậy vượt quá ngưỡng, quyền điều khiển được chuyển cho bộ điều phối xác định. LLM không bao giờ quyết định tệp nào cần chỉnh sửa tiếp theo, không bao giờ quyết định cách sắp xếp thứ tự cập nhật, không bao giờ quyết định liệu xác thực có thành công hay không.

💡 Thông Tin Chi Tiết Độc Đáo: Lược đồ đầu ra có cấu trúc cho việc phân loại ý định đã trải qua năm lần lặp trong sản xuất. Phiên bản đầu tiên trả về JSON tự do mà bộ điều phối phân tích thủ công — dẫn đến tỷ lệ lỗi phân tích 7% khi thử lại. Chuyển sang withStructuredOutput với lược đồ Zod đã định kiểu đã loại bỏ hoàn toàn lỗi phân tích. Bài học: nếu LLM tạo ra lược đồ, LLM cũng có thể vi phạm nó. Hãy sử dụng lược đồ được thực thi tại thời gian chạy cho mọi đầu ra có cấu trúc.

---

📊 Mẫu 2: Đồ Thị Phụ Thuộc Với Sắp Xếp Tô-Pô

Đồ thị phụ thuộc nằm trong một tệp nguồn duy nhất trong cơ sở hạ tầng của trình xây dựng — không được sao chép vào dữ liệu người thuê:

# patterns/common/dependency-graph.md
offerings_schema → order_schema → pricing_formula
                                 → scheduling_function
                                 → validation_function
router, callback, system_prompt (độc lập, không có phụ thuộc)
pricing, scheduling, validation (có thể chạy song song)

Bộ điều phối nhúng đồ thị này vào prompt hệ thống của nó và sử dụng nó để sắp xếp thứ tự tầng:

// Trích đoạn prompt bộ điều phối (diễn giải)
const DEPENDENCY_GRAPH = `
  Các kỹ năng khóa có thứ tự phụ thuộc chặt chẽ:
  1. offerings_schema (không có phụ thuộc)
  2. order_schema (phụ thuộc vào offerings_schema)
  3. pricing_formula (phụ thuộc vào order_schema)
  4. scheduling_function (phụ thuộc vào order_schema)
  5. validation_function (phụ thuộc vào order_schema)
  Các bước 3-5 có thể chạy song song sau khi bước 2 hoàn thành.
`;

const KNOWN_PATTERN_CASCADE = {
  'add-offering': ['offerings_schema', 'order_schema', 'pricing_formula', 'scheduling_function', 'validation_function'],
  'remove-offering': ['offerings_schema', 'order_schema', 'pricing_formula', 'scheduling_function', 'validation_function'],
  'update-price': ['offerings_schema', 'pricing_formula'],
};

Bộ điều phối ủy quyền cho các tác tử con chỉnh sửa, các tác tử này gửi công cụ tạo mã theo thứ tự tầng. Mỗi tác tử con tạo mã đọc đầu ra của các phụ thuộc thượng nguồn của nó:

// Prompt tác tử con tạo mã (diễn giải)
const pricingFormulaGenerator = {
  name: 'sales-assistant-pricing-formula-generator',
  tools: [readSkillFile, writeSkillFile, editSkillFile],
  prompt: `
    Bạn là trình tạo công thức định giá.
    Bạn PHẢI đọc offerings_types và order_types trước khi tạo.
    Đầu ra của bạn phụ thuộc vào các tệp thượng nguồn này.
  `,
};

Không có LLM nào quyết định tệp nào tiếp theo. Đồ thị là xác định.

💡 Thông Tin Chi Tiết Độc Đáo: Ban đầu đồ thị phụ thuộc chỉ tồn tại trong prompt của bộ điều phối dưới dạng ngôn ngữ tự nhiên. Sau hai sự cố sản xuất khi prompt bị trôi trong quá trình lặp (chúng tôi vô tình viết lại thứ tự tầng), chúng tôi đã trích xuất nó thành một tệp dependency-graph.md riêng mà cả prompt bộ điều phối và công việc CI đều đọc từ cùng một nguồn. Một nguồn duy nhất đã loại bỏ sự trôi.

---

🗂️ Mẫu 3: Vòng Đời Cơ Sở Kiến Thức Ngữ Nghĩa Git

Mỗi phiên chỉnh sửa coi cơ sở kiến thức như một kho lưu trữ kiểu git:

Staging (luồng chỉnh sửa)  →  Đề xuất tạo  →  Đã phê duyệt  →  Đưa lên sản xuất
                              Nhánh bị từ chối (bị loại bỏ)
                              Mục nhật ký kiểm toán cho mọi chuyển tiếp

Mô hình dữ liệu sử dụng năm bộ sưu tập để theo dõi lịch sử phiên bản bất biến:

// collections/business-code-base.collections.ts
interface BusinessCodeBaseStagingAreaDoc {
  threadId: string;          // một cho mỗi luồng chỉnh sửa
  baseGenerationId: ObjectId;
  overlay: Record<string, string>;  // key → versionId
  state: 'open' | 'sealed' | 'abandoned';
}

interface BusinessCodeBaseGenerationDoc {
  state: 'draft' | 'proposed' | 'approved' | 'rejected' | 'promoted' | 'rolled_back';
  sealedAt?: Date;
  approvedAt?: Date;
  promotedAt?: Date;
  rolledBackAt?: Date;
  rejectedAt?: Date;
}

Các thao tác vòng đời ánh xạ tới các điểm cuối REST với ngữ nghĩa nguyên tử:

POST /environments/seed        → Khởi tạo môi trường tiếp theo
POST /environments/promote     → Chuyển nhanh HEAD trực tiếp lên HEAD tiếp theo
POST /environments/rollback    → Di chuyển HEAD trực tiếp về phía sau
GET  /environments/diff        → Hiển thị các thay đổi đã stage so với trực tiếp
GET  /environments/history     → Nhật ký sự kiện bất biến

Việc thăng cấp sử dụng mẫu so-sánh-và-đổi (CAS) để ngăn chặn ghi đè đồng thời:

// ide.service.ts
async promote(tenantId: ObjectId, businessEntityId: ObjectId, generationId: ObjectId) {
  // CAS: chỉ thăng cấp nếu HEAD trực tiếp vẫn trỏ đến generation dự kiến
  const head = await this.getLiveHead(tenantId, businessEntityId);
  if (head.generationId !== expectedGenerationId) {
    throw new ConcurrentModificationError();
  }
  await this.swapGenerationPointer(environment, 'live', generationId);
  await this.recordEvent(tenantId, businessEntityId, {
    action: 'promote',
    generationId,
    previousHead: head.generationId,
  });
}

Không có bản cập nhật một phần nào đến được môi trường sản xuất. Nếu bất kỳ bước nào trong tầng thất bại, khu vực staging sẽ bị loại bỏ và generation không bao giờ đạt đến trạng thái proposed.

💡 Thông Tin Chi Tiết Độc Đáo: Điểm cuối rollback sử dụng cùng hàm swapGenerationPointer như thăng cấp — chỉ với ID generation trỏ đến một commit cũ hơn. Điều này có nghĩa là thăng cấp và rollback chia sẻ cùng các đảm bảo về đồng thời. Điểm khác biệt duy nhất là hướng của con trỏ HEAD. Khi chúng tôi thêm rollback, nó chỉ là một thay đổi 30 dòng, không phải một tính năng mới.

---

🎯 Mẫu 4: Các Mẫu Đã Biết So Với Tầng Tổng Quát

Các thao tác phổ biến chạy trên các quy trình được xây dựng có chủ đích — được gọi là kỹ năng. Mỗi kỹ năng là một tệp SKILL.md với một trình tự tầng được xác định trước:

patterns/
  add-offering/
    SKILL.md          ← "Đọc trạng thái, chỉnh sửa tham chiếu, tầng qua 5 trình tạo, xác thực"
    reference-template.md
  remove-offering/
    SKILL.md
  update-price/
    SKILL.md

Bộ điều phối định tuyến đến tác tử con thích hợp dựa trên phân loại ý định:

const orchestrator = createDeepAgent({
  name: 'sales-assistant-skill-builder',
  subagents: [
    knownPatternEditor,   // xử lý add-offering, remove-offering, update-price
    generalCascadeEditor, // xử lý bất kỳ thứ gì không khớp mẫu đã biết
    ...codeGenSubagents,  // 9 tác tử tạo mã
  ],
  tools: [readSkillFile],
  // Bộ điều phối KHÔNG BAO GIỜ ghi tệp trực tiếp — chỉ ủy quyền
});

Trình chỉnh sửa mẫu đã biết đọc SKILL.md phù hợp và làm theo hướng dẫn một cách chính xác. Trình chỉnh sửa tầng tổng quát xây dựng trình tự cập nhật từ đầu sử dụng đồ thị phụ thuộc.

const knownPatternEditor = {
  name: 'known-pattern-editor',
  prompt: `
    Bạn là trình chỉnh sửa mẫu đã biết. Bạn thực thi các mẫu cập nhật được xác định trước.
    Đọc SKILL.md, làm theo tầng một cách chính xác.
    Bạn làm việc trên một nhánh — tất cả ghi đều vào tệp của nhánh, không phải sản xuất.
  `,
};

const generalCascadeEditor = {
  name: 'general-cascade-editor',
  prompt: `
    Bạn là trình chỉnh sửa tầng tổng quát. Không có mẫu đã biết nào khớp với bản cập nhật này.
    Sử dụng đồ thị phụ thuộc để xác định thứ tự tầng.
    Bạn làm việc trên một nhánh — tất cả ghi đều vào tệp của nhánh, không phải sản xuất.
  `,
};

Bộ điều phối không bao giờ ghi tệp trực tiếp. Nó đọc trạng thái, lên kế hoạch thay đổi và ủy quyền cho các tác tử con chỉnh sửa. Các tác tử con sử dụng thao tác tìm-và-thay-thế — cùng mẫu mà một nhà phát triển sử dụng trong IDE — không phải trình phân tích cú pháp markdown tùy chỉnh hay thao tác chuỗi mong manh.

💡 Thông Tin Chi Tiết Độc Đáo: Chúng tôi bắt đầu với một tác tử chỉnh sửa đa năng duy nhất xử lý mọi thứ. Hệ thống mẫu đã biết xuất hiện sau khi quan sát thấy 73% các bản cập nhật trong sản xuất thuộc ba loại: thêm dịch vụ, xóa dịch vụ, cập nhật giá. Xây dựng một mẫu SKILL.md cho mỗi loại đã cắt giảm thời gian cập nhật 60% và giảm lỗi xác thực 80% vì trình tự tầng được mã hóa cứng thay vì được suy ra lại mỗi lần.

---

💬 Mẫu 5: Cập Nhật Theo Hội Thoại

Tác tử hỏi trước khi thực hiện tầng. Một câu hỏi làm rõ duy nhất ngăn chặn một tầng năm tệp được xây dựng trên các giả định sai:

Người dùng: "Thêm massage Thái, 200 baht."

Tác tử: "Tôi có thể thêm massage Thái với giá 200 baht. Nó thuộc danh mục nào?
        (các danh mục hiện tại: massage, facial, body treatment)"

Sau khi đọc trạng thái hiện tại, tác tử đề xuất các thay đổi liên quan một cách chủ động:

Tác tử: "Tôi thấy bạn có các loại dầu trị liệu bằng hương thơm.
        Tôi có nên thêm dầu phụ cho massage Thái không?
        Massage Thái thường bao gồm tùy chọn thoa dầu."

Sau khi cập nhật thành công, tác tử đưa ra các quan sát:

Tác tử: "Đã cập nhật. Hàm lên lịch hiện bao phủ 12 dịch vụ,
        nhưng lịch của bạn chỉ hỗ trợ 8 đặt chỗ đồng thời.
        Hãy cân nhắc mở rộng công suất trong giờ cao điểm."

Đây không phải là sự gián đoạn quy trình. Chúng chính là sản phẩm. Phiên cập nhật là một cuộc trò chuyện — không phải một giao dịch lệnh-thực thi-hoàn thành.

Prompt của bộ điều phối thực thi hành vi này ở cấp độ hệ thống:

Bạn là bộ điều phối. Bạn ĐỌC tệp, đặt câu hỏi làm rõ,
LÊN KẾ HOẠCH thay đổi và ỦY QUYỀN cho các tác tử con chỉnh sửa.
Bạn KHÔNG BAO GIỜ gọi write_skill_file hoặc edit_skill_file trực tiếp.
Bạn suy nghĩ từng bước một.

💡 Thông Tin Chi Tiết Độc Đáo: Mẫu “hỏi trước khi tầng” xuất hiện từ một sự cố sản xuất khi người dùng nói “xóa massage thai kỳ” — và tác tử đã xóa nó khỏi danh mục, công thức định giá, hàm lên lịch và hàm xác thực. Người dùng muốn “ẩn nó khỏi trang đặt chỗ,” không phải “xóa nó khỏi hệ thống.” Thêm một câu hỏi làm rõ duy nhất (“ẩn hay xóa?”) đã loại bỏ hoàn toàn loại sự cố này.

---

🧪 Mẫu 6: Đường Ống Xác Thực Trước Khi Commit

Mọi generation được đề xuất phải vượt qua xác thực trước khi có thể đạt đến trạng thái approved. Đường ống xác thực chạy bốn bước kiểm tra:

Xác thực lược đồ. Lược đồ JSON được kiểm tra theo draft 2020-12. Tất cả các tham chiếu chéo giữa các lược đồ phải được giải quyết.

Xác minh phạm vi bao phủ. Công thức định giá phải bao phủ mọi dịch vụ trong danh mục. Nếu danh mục liệt kê “Massage Thái 60 phút” và “Massage Thái 90 phút,” công thức định giá phải xử lý cả hai.

Biên dịch TypeScript. Mã được tạo sẽ biên dịch trong hộp cát vm.Context với thời gian chờ 5 giây:

import * as vm from 'vm';

const SANDBOX_TIMEOUT_MS = 5000;

function validateGeneratedCode(code: string, functionName: string): boolean {
  const sandbox = {
    Date, Math, Array, Object, JSON,
    String, Number, Boolean, RegExp,
    parseInt, parseFloat, isNaN, isFinite,
  };

  const context = vm.createContext(sandbox, {
    name: 'ValidationSandbox',
    codeGeneration: { strings: false, wasm: false },
  });

  try {
    new vm.Script(`"use strict";\n${code}\n${functionName}`, {
      filename: `validation-${functionName}.js`
    }).runInContext(context, { timeout: SANDBOX_TIMEOUT_MS });
    return true;
  } catch {
    return false;
  }
}

Tính toàn vẹn của phụ thuộc. Mọi tệp được tham chiếu trong generation phải tồn tại. Không có import lơ lửng, không có lược đồ mồ côi.

Nếu bất kỳ bước kiểm tra nào thất bại, toàn bộ generation sẽ bị từ chối — khu vực staging bị loại bỏ và diff không bao giờ đến được sản xuất.

async function sealAndValidate(stagingArea: StagingArea): Promise<Generation | null> {
  // Niêm phong khu vực staging thành một generation đề xuất
  const generation = await sealStagingAreaIntoGeneration(stagingArea);

  // Chạy đường ống xác thực
  const schemasValid = await validateSchemas(generation);
  const coverageValid = await verifyCoverage(generation);
  const compilationValid = await compileGeneratedCode(generation);
  const integrityValid = await checkDependencies(generation);

  if (!schemasValid || !coverageValid || !compilationValid || !integrityValid) {
    await updateGenerationState(generation._id, 'rejected');
    await abandonStagingArea(stagingArea.threadId);
    return null;
  }

  return generation; // sẵn sàng cho người vận hành phê duyệt
}

💡 Thông Tin Chi Tiết Độc Đáo: Bước kiểm tra biên dịch đã phát hiện ra một lỗi trong tuần đầu tiên sản xuất: trình tạo công thức định giá tạo ra JavaScript tham chiếu this bên trong một hàm mũi tên — JavaScript hợp lệ nhưng không chính xác khi thực thi trong ngữ cảnh hộp cát. Quá trình biên dịch hộp cát thất bại trên các lỗi cú pháp và lỗi tham chiếu, phát hiện tại thời điểm xây dựng những gì nếu không sẽ xuất hiện dưới dạng giá NaN bí ẩn trong sản xuất.

---

⚠️ Những Gì Không Hiệu Quả

Quản lý tầng chỉ bằng LLM. Phiên bản đầu tiên có một tác tử duy nhất chỉnh sửa tất cả các tệp tuần tự. Nó hoạt động 60% thời gian. 40% còn lại nó bỏ qua tệp, sắp xếp lại tầng hoặc tạo ra sự không nhất quán. Cách tiếp cận đồ thị phụ thuộc là nỗ lực thứ hai của chúng tôi và nâng tỷ lệ thành công lên ~95%. 5% còn lại cần đường ống xác thực làm lưới an toàn.

Trình định vị dịch vụ toàn cục cho DI. Trước khi phân lớp DI theo mức phụ thuộc, chúng tôi có một danh sách đăng ký phẳng. Khi hai dịch vụ phát triển phụ thuộc vòng tròn, lỗi xuất hiện khi khởi động máy chủ — nhưng chỉ trong sản xuất, vì các bài kiểm tra không đăng ký toàn bộ đồ thị. Chuyển sang các mức phụ thuộc rõ ràng giúp phát hiện các phụ thuộc vòng tròn trong quá trình đánh giá mã.

Cho phép bộ điều phối ghi tệp. Trong kiến trúc đầu tiên, bộ điều phối xử lý cả lập kế hoạch và thực thi. Khi một tầng thất bại giữa chừng, các ghi tệp của bộ điều phối đã được cam kết. Tách lập kế hoạch (bộ điều phối) khỏi thực thi (các tác tử con chỉnh sửa) là sửa chữa kiến trúc giúp rollback sạch sẽ.

---

📊 Số Liệu Hiệu Suất

Đo trong sản xuất từ trình xây dựng kỹ năng của QuotyAI:

Chỉ số	Giá trị
Phân loại ý định	~800ms
Tầng mẫu đã biết (5 tệp)	~12s
Tầng tổng quát (5 tệp)	~25s
Đường ống xác thực	~3s
Biên dịch hộp cát	<100ms
Thăng cấp (CAS)	<50ms
Rollback (CAS)	<50ms
Tỷ lệ thành công cập nhật (mẫu đã biết)	95%
Tỷ lệ thành công cập nhật (tầng tổng quát)	83%
Tỷ lệ phát hiện xác thực	100% các tầng thất bại

12 giây cho một tầng mẫu đã biết bao gồm tất cả 5 lần gọi LLM để tạo mã, mỗi lần tạo một tệp. Đường ống xác thực phát hiện mọi lỗi tầng — không có trạng thái không nhất quán nào đến được sản xuất kể từ khi đường ống được triển khai.

---

📋 Công Nghệ Sử Dụng

Lớp	Công nghệ
Khung tác tử	deepagents
Đầu ra có cấu trúc	Gemini + lược đồ Zod 4.x
Thực thi hộp cát	Node.js vm.createContext
Lưu trữ	MongoDB native driver
DI	tsyringe với 8 mức phụ thuộc
API vòng đời	Hono + xác thực Zod

---

📋 Khi Nào Nên Sử Dụng Kiến Trúc Này

Sử dụng cách tiếp cận này khi:

• Hệ thống AI của bạn tạo mã hoặc dữ liệu có cấu trúc phụ thuộc vào các tài nguyên được tạo khác
• Bạn cần cập nhật nguyên tử trên nhiều tệp phụ thuộc lẫn nhau
• Người vận hành phải xem xét các thay đổi trước khi chúng được đưa vào hoạt động
• Bạn muốn có dấu vết kiểm toán rõ ràng cho mọi sửa đổi

Bỏ qua khi:

• Nội dung của bạn độc lập (không có chuỗi phụ thuộc giữa các tài nguyên)
• Bạn không cần sự phê duyệt của người vận hành cho các thay đổi
• Đầu ra do LLM tạo không có người tiêu dùng hạ nguồn
• Bạn có thể chấp nhận lỗi cập nhật một phần

---

TL;DR

Danh mục	Mẫu
Vấn đề	Cập nhật logic kinh doanh tầng qua 5+ tệp phụ thuộc lẫn nhau
Kiến trúc	LLM trích xuất ý định → thực thi tầng xác định
Đồ thị phụ thuộc	Sắp xếp tô-pô: offerings → order → pricing + scheduling + validation
Vòng đời	Kiểu git: staging → propose → approve → promote → rollback
Quy trình	Mẫu đã biết (SKILL.md) cho thao tác phổ biến, tầng tổng quát cho thao tác mới
Hội thoại	Tác tử đặt câu hỏi làm rõ trước khi thực hiện tầng
Xác thực	Kiểm tra lược đồ + xác minh phạm vi + biên dịch hộp cát + tính toàn vẹn phụ thuộc
Điều phối	Bộ điều phối lập kế hoạch + ủy quyền. Không bao giờ ghi tệp trực tiếp.

---

Đọc Thêm

• Determinism as Infrastructure — tại sao thực thi xác định là nền tảng
• The Deterministic Bet — lý do đằng sau việc xây dựng các tác tử AI đáng tin cậy
• Hono + Bun for AI Platforms: 6 Production Patterns — cơ sở hạ tầng backend mà các mẫu này chạy trên

---

Các Câu Hỏi Thường Gặp

Làm thế nào để cập nhật logic kinh doanh do AI tạo một cách an toàn trong môi trường sản xuất? Sử dụng ngữ nghĩa kiểu git: các chỉnh sửa được đưa vào nhánh staging, không phải sản xuất. Bộ điều phối thực hiện sắp xếp tô-pô trên đồ thị phụ thuộc, ủy quyền tạo mã cho từng nút, sau đó chạy xác thực. Nếu bất kỳ bước kiểm tra nào thất bại, việc cập nhật bị hủy bỏ. Người vận hành xem xét và phê duyệt diff trước khi đưa lên sản xuất.

Làm thế nào để ngăn LLM làm hỏng các tệp logic kinh doanh phụ thuộc lẫn nhau? LLM chỉ xử lý trích xuất ý định — chuyển đổi ngôn ngữ tự nhiên thành dữ liệu có cấu trúc với lược đồ Zod đã định kiểu. Mọi thứ sau bước trích xuất đều chạy trên mã xác định: đồ thị phụ thuộc xác định thứ tự tầng, các tác tử con tạo mã sản xuất từng tệp, đường ống xác thực kiểm tra lược đồ và biên dịch TypeScript, và toàn bộ quá trình cập nhật bị hủy bỏ nguyên tử nếu bất kỳ bước nào thất bại.

Sự khác biệt giữa các mẫu đã biết và tầng tổng quát trong quy trình AI tác tử là gì? Các mẫu đã biết là những quy trình được xây dựng có chủ đích cho các thao tác phổ biến như thêm dịch vụ hoặc cập nhật giá. Mỗi mẫu có một tệp SKILL.md với trình tự tầng được xác định trước. Tầng tổng quát xử lý các thao tác không khớp với bất kỳ mẫu đã biết nào, xây dựng trình tự cập nhật từ đầu dựa trên đồ thị phụ thuộc.

Làm thế nào để xác thực mã do AI tạo trước khi nó đến môi trường sản xuất? Đường ống xác thực kiểm tra lược đồ JSON theo chuẩn draft 2020-12, giải quyết tất cả các tham chiếu chéo, xác minh công thức định giá bao phủ mọi dịch vụ, và biên dịch TypeScript trong hộp cát vm.createContext của Node.js với thời gian chờ 5 giây. Nếu bất kỳ bước kiểm tra nào thất bại, toàn bộ quá trình cập nhật bị hủy bỏ nguyên tử.

Điều gì xảy ra khi một tầng cập nhật thất bại giữa chừng? Tính nguyên tử được xây dựng vào vòng đời. Khu vực staging được niêm phong thành một generation đề xuất, đường ống xác thực chạy tất cả các bước kiểm tra, và nếu bất kỳ bước kiểm tra nào thất bại, generation được đánh dấu là rejected và khu vực staging bị loại bỏ. Không có trạng thái một phần nào đến được sản xuất. Người vận hành thấy một generation bị từ chối với dấu vết kiểm toán đầy đủ.

---

Tags: ai-agents business-logic code-generation typescript multi-agent deterministic-ai