GitHub Copilot Cho JetBrains 2026: OpenTelemetry, MCP, Codex Và Quản Trị Agent

GitHub Copilot trên hệ sinh thái JetBrains đang chuyển từ một khung chat hỗ trợ lập trình thành một lớp điều phối nhiều agent ngay trong IDE. Bản cập nhật công bố ngày 27/7/2026 bổ sung cấu hình OpenTelemetry chi tiết hơn, giới hạn token cho mô hình tùy chỉnh, quản lý mô hình và hỗ trợ MCP cùng custom agent trong luồng Claude. Khi đặt cạnh đợt cập nhật ngày 7/7 và 13/5, bức tranh lớn hiện ra khá rõ: đội kỹ thuật có thể chọn agent, cô lập phiên làm việc, đặt ranh giới quyền, quan sát tool call và kiểm soát chi phí mà không rời IntelliJ IDEA, PyCharm, WebStorm hay các IDE JetBrains tương thích.

Điều đáng chú ý không nằm ở số lượng nút mới. Giá trị thật là khả năng biến “vibe coding” từ thử nghiệm cá nhân thành quy trình có bằng chứng: biết agent nào đã chạy, dùng mô hình nào, gọi công cụ gì, tiêu thụ bao nhiêu token, thao tác trong workspace hay worktree, và ai đã chấp nhận mức quyền tự động. Bài này phân tích từng lớp của hệ thống, chỉ rõ trạng thái GA hay preview, rồi đề xuất một playbook triển khai an toàn cho nhóm phát triển.

Tóm tắt nhanh: bản cập nhật thay đổi điều gì?

Theo GitHub Changelog ngày 27/7/2026, GitHub Copilot cho JetBrains có năm nhóm thay đổi quan trọng.

• OpenTelemetry có trang cấu hình rõ hơn để bật xuất dữ liệu, chọn giao thức và endpoint.
• Mô hình BYOK hoặc endpoint tùy chỉnh có thể nhận giới hạn token đầu vào và đầu ra.
• Người dùng có thể bật hoặc tắt mô hình tích hợp trong danh sách lựa chọn.
• MCP server và custom agent được đưa vào luồng Claude agent.
• Copilot CLI sessions có thêm fork, lệnh /rubber-duck, danh sách việc cần làm và các cải tiến chẩn đoán.

Đây không phải tuyên bố rằng mọi tính năng agent trong JetBrains đều đã GA. Bản cập nhật ngày 7/7/2026 ghi rõ Codex agent provider còn ở public preview; Autopilot cũng mang nhãn Preview. Trong cùng đợt đó, Inline Chat mới là phần được GitHub xác nhận general availability. Việc phân biệt trạng thái này rất quan trọng khi xây chính sách cho môi trường production: tính năng preview nên có nhóm thử nghiệm, phạm vi repository và kế hoạch quay lui riêng.

Nếu đang so sánh hình thức làm việc, bài Terminal Agent, IDE Agent và Cloud Agent cung cấp khung chọn môi trường theo mức độ tương tác, cô lập và thời gian chạy. Còn bài hiện tại tập trung vào trường hợp JetBrains đóng vai trò bảng điều khiển cho nhiều provider.

OpenTelemetry biến phiên agent thành dữ liệu vận hành

OpenTelemetry không làm agent viết mã tốt hơn một cách trực tiếp. Nó làm cho quá trình sử dụng agent có thể quan sát, đo lường và điều tra. Trong một thử nghiệm nhỏ, developer có thể nhớ mình vừa gửi prompt gì và chấp thuận lệnh nào. Với hàng chục repository và nhiều agent provider, trí nhớ cá nhân không còn đủ để trả lời những câu hỏi cơ bản: độ trễ tăng ở bước nào, tool call nào thất bại, mô hình nào tạo nhiều vòng lặp, hoặc phiên nào tiêu thụ ngân sách bất thường.

Trang cấu hình mới trong JetBrains cho phép bật xuất telemetry, chọn giao thức OTLP và đặt endpoint. Đây là điểm nối giữa trải nghiệm trong IDE với hệ thống quan sát tập trung của tổ chức. Tuy nhiên, bật export không đồng nghĩa nên thu mọi thứ. Giao diện có tùy chọn liên quan đến việc ghi prompt và response; đây là vùng nhạy cảm vì nội dung có thể chứa đoạn mã độc quyền, tên khách hàng, đường dẫn nội bộ, khóa thử nghiệm hoặc mô tả lỗ hổng chưa công bố.

Một cấu hình lành mạnh nên bắt đầu bằng metadata có rủi ro thấp: thời lượng phiên, thời gian phản hồi, số vòng model, số tool call, kết quả thành công hoặc lỗi, loại agent, tên mô hình và lượng token. Chỉ bật thu nội dung prompt/response khi đã có mục đích cụ thể, cơ chế lọc, thời hạn lưu giữ, phân quyền truy cập và thông báo rõ cho developer. Nếu hệ thống quan sát không hỗ trợ loại bỏ bí mật, lựa chọn an toàn là để tùy chọn capture nội dung ở trạng thái tắt.

Đừng biến OpenTelemetry thành bảng xếp hạng cá nhân. Số prompt, token hoặc tool call không phản ánh chất lượng kỹ sư. Nên dùng dữ liệu để tìm nghẽn hệ thống, đánh giá độ ổn định của provider, phát hiện vòng lặp và kiểm tra hiệu quả của guardrail. Một phiên ít token nhưng tạo regression vẫn kém hơn phiên dài hơn có test và review đầy đủ.

Giới hạn token biến BYOK thành cấu hình có kiểm soát

BYOK và endpoint tùy chỉnh giúp tổ chức dùng mô hình phù hợp với chính sách dữ liệu hoặc hợp đồng riêng. Nhưng nếu IDE không biết context window và giới hạn output, trải nghiệm dễ thất thường: prompt bị cắt, agent yêu cầu quá nhiều ngữ cảnh, response dừng giữa patch, hoặc chi phí tăng mà không có cảnh báo rõ ràng.

Bản cập nhật mới cho phép đặt maxInputToken và maxOutputToken khi thêm mô hình. Đây là hai con số có tác động khác nhau. Giới hạn đầu vào quyết định lượng code, instruction, lịch sử và kết quả tool có thể đi vào một lượt. Giới hạn đầu ra ảnh hưởng độ dài kế hoạch, patch hay giải thích mà mô hình có thể trả về. Đặt cả hai bằng mức tối đa của nhà cung cấp chưa chắc tối ưu; context lớn làm tăng độ trễ và có thể khiến agent mang theo nhiều dữ liệu không cần thiết.

Hãy cấu hình theo ba lớp. Lớp đầu là giới hạn kỹ thuật do endpoint công bố. Lớp thứ hai là giới hạn ngân sách của tổ chức. Lớp thứ ba là profile tác vụ: review một file cần ít context hơn refactor nhiều module. Nếu plugin chỉ hỗ trợ một cấu hình cho mỗi model, chọn mức bảo thủ làm mặc định và yêu cầu tác vụ lớn chuyển sang model hoặc agent profile riêng.

Tool calling và vision cũng phải khớp năng lực thật của endpoint. Đừng bật cờ chỉ vì giao diện cho phép; agent có thể lập kế hoạch dựa trên công cụ mà model không thực thi ổn định. Trước rollout, chạy một bộ kiểm thử gồm đọc file, sửa nhỏ, gọi terminal có xác nhận, tạo test và xử lý response dài. Ghi lại tỷ lệ hoàn thành, lỗi parse tool và số lượt lặp.

Quản lý mô hình: ít lựa chọn nhưng đúng chính sách

Danh sách mô hình dài tạo cảm giác linh hoạt nhưng làm tăng sai lệch giữa các developer. Hai người cùng xử lý một issue có thể dùng model khác nhau, chế độ reasoning khác nhau và chi phí khác nhau mà không nhận ra. Tính năng bật hoặc tắt built-in models giúp giảm nhiễu tại điểm chọn.

Một model catalog cho nhóm nên có tên hiển thị dễ hiểu, phạm vi sử dụng, tình trạng preview hay production, mức dữ liệu được phép, giới hạn token và chủ sở hữu cấu hình. Có thể chia thành ba nhóm: model mặc định cho tác vụ hàng ngày, model mạnh cho thay đổi phức tạp có phê duyệt, và model thử nghiệm chỉ dành cho sandbox. Model bị tắt không nhất thiết là model kém; có thể chỉ chưa hoàn tất đánh giá pháp lý, chưa đáp ứng vùng dữ liệu hoặc có biến động chi phí.

Với Copilot Business và Enterprise, custom model do quản trị viên cấu hình có thể xuất hiện cho thành viên. Vì vậy, quản trị catalog và cấu hình trong IDE cần được nhìn như một chuỗi thống nhất. Nếu admin đổi model phía tổ chức mà tài liệu nội bộ không đổi, developer khó hiểu vì sao kết quả hoặc giới hạn khác đi. Mỗi thay đổi nên có ngày hiệu lực, release note và cách báo sự cố.

Claude agent flow: Instructions, Skills và MCP trên cùng mặt phẳng

Luồng Claude agent trong JetBrains nay hiển thị các nhóm Instructions, Skills và MCP Servers trong Agent Customizations. Sự gom nhóm này phản ánh kiến trúc agent thực tế: model chỉ là một phần; hành vi còn phụ thuộc vào instruction, kỹ năng đóng gói và công cụ bên ngoài.

Instructions nên chứa quy tắc ổn định của repository: lệnh test, chuẩn coding, vùng không được sửa và tiêu chí hoàn thành. Skill nên mô tả quy trình tái sử dụng như tạo migration, kiểm tra accessibility hoặc chuẩn bị release. MCP server mở thêm năng lực đọc tài liệu, issue, database hay dịch vụ nội bộ. Khi ba lớp được quản lý chung, đội ngũ dễ xác định một phiên agent đã nhận những quyền và ngữ cảnh nào.

Rủi ro lớn nhất là xem MCP như “plugin tiện lợi” thay vì biên giới tin cậy. Mỗi server cần có chủ sở hữu, nguồn cài đặt, version pin, danh sách tool, phạm vi credential và môi trường được phép. Ưu tiên tool chỉ đọc; tách server đọc và ghi; tránh đưa token production vào cấu hình workspace. Tệp .github/mcp.json thuận tiện để chia sẻ cấu hình ở cấp dự án, nhưng bí mật phải đến từ secret store hoặc cơ chế môi trường, không commit vào Git.

Khi cần xây quy trình kết nối GitHub qua MCP, có thể tham khảo hướng dẫn migration GitHub MCP Server. Nguyên tắc chung vẫn là tối thiểu quyền, xác thực nguồn server và ghi lại thay đổi cấu hình.

Codex trở thành agent provider trong JetBrains

GitHub công bố Codex như một agent provider ở public preview ngày 7/7/2026. Để dùng, máy cần cài Codex CLI, sau đó bật Codex và khai báo đường dẫn CLI trong Settings > Tools > GitHub Copilot > Chat. Khi hoàn tất, Codex có thể được chọn từ agent picker của Copilot Chat.

Mô hình provider cho phép developer giữ một bề mặt làm việc quen thuộc trong JetBrains nhưng đổi “động cơ” tùy nhiệm vụ. Lợi ích là giảm chuyển ngữ cảnh giữa terminal, trình duyệt và IDE. Đổi lại, nhóm phải làm rõ provider nào chịu trách nhiệm cho session, provider nào được phép gọi terminal, và dữ liệu đi qua chính sách nào. Đừng giả định mọi agent trong cùng panel có quyền, log và cách tính usage giống nhau.

Vì Codex provider còn preview, rollout hợp lý là chọn repository không chứa dữ liệu nhạy cảm, giới hạn nhóm pilot và yêu cầu review bắt buộc. Kiểm thử đường dẫn CLI trên macOS, Windows và Linux; xác nhận hành vi khi binary thiếu, version lệch hoặc phiên đăng nhập hết hạn. Tài liệu nội bộ cũng cần chỉ rõ cách quay về Local agent hoặc Copilot CLI khi provider lỗi.

Nếu nhóm dùng Codex ở nhiều bề mặt, bài Codex App, CLI và IDE: workflow review và automation giúp phân biệt tác vụ phù hợp với từng môi trường.

Agent Customizations: quản lý Hooks, MCP và tệp cấu hình

Agent Customizations bổ sung Hooks và quản lý MCP server cho local sessions lẫn Copilot CLI sessions. Với MCP, giao diện hỗ trợ server kiểu command và HTTP, xem trạng thái, start, stop, restart hoặc uninstall. GitHub cũng cho phép cấu hình server cấp workspace bằng .github/mcp.json.

Hooks mạnh vì chúng biến quy tắc thành hành động tự động: chạy formatter, chặn file nhạy cảm, thu thập log hoặc kích hoạt kiểm tra. Nhưng hook cũng là code có thể chạy trong máy developer. Quy trình review hook nên tương đương script build: pin dependency, tránh tải code động, giới hạn biến môi trường, timeout hợp lý và log lỗi rõ ràng. Hook thất bại không được âm thầm bỏ qua kiểm soát quan trọng.

Khả năng scaffold /create-instruction, /create-prompt, /create-skill, /create-agent hoặc /create-hook giúp bắt đầu nhanh, nhưng file do AI tạo phải được review như source code. Kiểm tra scope, câu lệnh shell, đường dẫn tuyệt đối, tham chiếu secret và giả định về hệ điều hành. Một custom agent tốt cần mục tiêu hẹp, output contract rõ và tiêu chí dừng; tránh agent “làm mọi thứ” với quyền rộng.

Ba mức quyền của Copilot CLI: Default, Bypass và Autopilot

Copilot CLI sessions trong JetBrains có ba mức approval. Default Approvals tuân theo chính sách xác nhận hiện tại và hỏi lại khi cần. Bypass Approvals tự động chấp thuận tool call nhưng agent vẫn có thể hỏi câu làm rõ. Autopilot, ở trạng thái Preview, vừa tự động chấp thuận tool call vừa tự trả lời câu làm rõ để tiếp tục lặp đến khi hoàn thành.

Ba mức này không phải thang “nhanh hơn thì tốt hơn”. Chúng là ba mô hình rủi ro. Default phù hợp với repository thật, nhiệm vụ chưa biết trước và máy có credential. Bypass chỉ nên dùng trong sandbox hoặc worktree có phạm vi hẹp, khi command allowlist và khả năng hoàn tác đã rõ. Autopilot nên được xem như một worker tự động: cần timeout, giới hạn vòng lặp, ngân sách, không có secret production và tiêu chí dừng bên ngoài model.

Một anti-pattern phổ biến là bật Bypass để tránh phiền rồi làm việc trực tiếp trên branch đang mở. Agent có thể cài package, sửa file cấu hình hoặc chạy command destructive trước khi developer kịp nhận ra. Tốc độ chỉ có ý nghĩa khi vùng tác động bị giới hạn. Worktree riêng, user không đặc quyền và test environment là ba lớp giảm thiểu cơ bản.

Permission mode riêng cho Claude agent

Claude agent sessions có permission mode riêng trong vùng nhập chat. Điều này nhắc rằng “permission” không phải thuộc tính chung của toàn IDE; nó có thể khác theo provider và từng phiên. Người dùng phải kiểm tra mode hiện tại trước nhiệm vụ, đặc biệt sau khi mở lại session hoặc chuyển agent.

Trong chính sách nội bộ, hãy mô tả hành vi thay vì chỉ ghi tên mode, vì nhãn có thể thay đổi giữa phiên bản. Ví dụ: “mọi sửa file cần xác nhận”, “được tự động sửa trong worktree nhưng không chạy command mạng”, hoặc “chỉ lập kế hoạch, không ghi”. Khi onboarding, yêu cầu developer thực hành một nhiệm vụ giả để thấy dialog xác nhận và vị trí đổi mode.

Không nên dùng permission mode để thay thế bảo mật hệ điều hành. Nếu agent chạy trong tài khoản có quyền truy cập production, một click nhầm vẫn có hậu quả lớn. Quyền IDE, quyền hệ thống file, credential và network policy phải cùng bảo vệ ranh giới.

Debug logs và OpenTelemetry phục vụ hai tầng quan sát

Agent Debug Logs hiển thị chi tiết session như model turns, tool calls, lượng token, lỗi và trạng thái. Đây là công cụ điều tra cục bộ: developer có thể mở một phiên cụ thể để hiểu agent dừng ở đâu. OpenTelemetry phục vụ góc nhìn hệ thống: so sánh xu hướng qua nhiều phiên, repository và thời gian.

Hai lớp không thay thế nhau. Debug log có ngữ cảnh sâu nhưng dễ chứa dữ liệu nhạy cảm; telemetry có thể được chuẩn hóa và giảm chi tiết. Playbook sự cố nên bắt đầu từ tín hiệu tổng hợp, xác định session bất thường, rồi chỉ cấp quyền xem debug log cho người cần điều tra. Khi chia sẻ log vào issue, loại bỏ prompt, đường dẫn, tên người dùng, token và nội dung source không cần thiết.

Các metric hữu ích gồm tỷ lệ session hoàn thành, tỷ lệ tool call lỗi, thời gian chờ model, số vòng lặp trước khi có patch, tỷ lệ test pass lần đầu và số lần developer phải sửa lại. Đừng tối ưu “số dòng code do AI tạo”; metric này khuyến khích output lớn và bỏ qua chất lượng.

Unified Sessions và cách cô lập bằng worktree

Đợt cập nhật ngày 13/5/2026 giới thiệu Copilot CLI agent và Unified Sessions. Sessions view gom các phiên để người dùng chuyển đổi và tiếp tục công việc. Copilot CLI agent có thể chạy trong workspace hiện tại hoặc worktree cô lập.

Worktree là lựa chọn mặc định tốt cho nhiệm vụ agent dài hoặc có phạm vi sửa nhiều file. Nó tách thay đổi khỏi working tree đang dùng, giảm xung đột với thao tác của developer và làm việc xóa phiên trở nên rõ ràng hơn. Tuy vậy, worktree không phải container bảo mật: process vẫn có thể thấy credential, network và file ngoài repository nếu tài khoản hệ điều hành cho phép.

Đặt tên session theo issue hoặc mục tiêu, không theo prompt ngẫu hứng. Trước khi merge, developer phải đọc diff, chạy test từ môi trường sạch và xác nhận không có file sinh thừa. Khi một agent fork session, ghi rõ fork phục vụ giả thuyết nào; nếu không, danh sách phiên nhanh chóng thành lịch sử khó kiểm toán.

Quy trình rollout bốn giai đoạn cho product team

Giai đoạn 1: Baseline và inventory

Liệt kê IDE/version, plugin version, agent provider, model, MCP server và customizations hiện có. Chọn hai repository mẫu: một dự án nhỏ với test tốt và một dự án đại diện cho kiến trúc thật. Ghi baseline về thời gian xử lý issue, lỗi test và mức can thiệp của developer trước khi bật thêm tự động hóa.

Giai đoạn 2: Pilot có ranh giới

Bật OpenTelemetry chỉ với metadata; tắt capture prompt/response. Chỉ cho phép Default Approvals, MCP read-only và worktree. Chọn năm đến mười tác vụ có tiêu chí hoàn thành rõ: cập nhật dependency nhỏ, thêm test, sửa lint, viết tài liệu hoặc refactor cục bộ. Mỗi nhiệm vụ phải có người review và nhãn provider/model.

Giai đoạn 3: Mở rộng theo bằng chứng

Phân tích session thất bại, điều chỉnh instructions và token limits. Chỉ thêm Bypass cho tác vụ lặp lại trong sandbox. Đưa custom agent hoặc skill vào repository sau code review. Thiết lập owner cho từng MCP server và dashboard về độ trễ, lỗi tool call, token và test pass.

Giai đoạn 4: Governance liên tục

Review model catalog và provider hàng tháng; review MCP, hooks và custom agents mỗi quý hoặc khi có release lớn. Tự động cảnh báo khi plugin version quá cũ, server MCP mất owner hoặc telemetry không về. Duy trì kill switch: tắt model, provider, MCP hoặc agent customization mà không cần sửa từng máy thủ công.

Checklist cấu hình an toàn

• Xác nhận trạng thái GA, public preview hoặc experimental của từng tính năng.
• Pin và kiểm tra Codex CLI, plugin JetBrains cùng dependency liên quan.
• Dùng Default Approvals làm mặc định; giới hạn Bypass và Autopilot vào sandbox.
• Dùng worktree cho nhiệm vụ nhiều file; không coi worktree là security sandbox.
• Chỉ bật MCP server có owner, nguồn, version và tool scope rõ ràng.
• Không commit credential vào .github/mcp.json hay customizations.
• Đặt giới hạn input/output token theo model và ngân sách.
• Tắt model không được phê duyệt hoặc chưa có đánh giá dữ liệu.
• Thu telemetry tối thiểu; tắt nội dung prompt/response nếu chưa có kiểm soát.
• Đặt retention và phân quyền cho debug logs.
• Review diff, test và dependency trước mọi merge.
• Có quy trình rollback khi provider, model hoặc plugin thay đổi hành vi.

Những lỗi triển khai thường gặp

Lỗi thứ nhất là bật mọi provider và model cho toàn tổ chức ngay ngày đầu. Kết quả là khó so sánh chất lượng, khó hỗ trợ và khó truy nguồn khi có regression. Hãy bắt đầu với một catalog nhỏ.

Lỗi thứ hai là cho MCP quyền ghi trước khi hiểu tool schema. Agent có thể gọi đúng tên tool nhưng truyền phạm vi rộng hơn mong đợi. Hãy quan sát call ở chế độ read-only, bổ sung confirmation và chỉ mở write cho use case có idempotency.

Lỗi thứ ba là lấy log để đánh giá hiệu suất cá nhân. Cách dùng này làm developer né công cụ hoặc tối ưu metric. Log nên phục vụ reliability, bảo mật và thiết kế guardrail.

Lỗi thứ tư là nhầm trạng thái preview với cam kết ổn định. Codex provider và Autopilot có thể thay đổi UX hoặc hành vi. Luôn có fallback và không phụ thuộc độc quyền vào feature preview trong quy trình phát hành.

Lỗi thứ năm là tin rằng agent đã “hoàn thành” khi panel báo done. Tiêu chí hoàn thành phải nằm ngoài model: test pass, lint sạch, review diff, không có secret và đáp ứng acceptance criteria.

Câu hỏi thường gặp

OpenTelemetry có gửi toàn bộ source code không?

Không nên mặc định như vậy. Dữ liệu thực tế phụ thuộc cấu hình export và tùy chọn capture. Hãy bắt đầu bằng metadata, kiểm tra payload ở collector thử nghiệm và chỉ thu prompt/response khi có mục đích cùng kiểm soát dữ liệu rõ ràng.

Có nên bật Autopilot cho repository production?

Không nên dùng làm mặc định. Autopilot còn ở Preview và tự động xử lý cả tool call lẫn câu làm rõ. Nếu thử nghiệm, hãy dùng worktree hoặc sandbox, tài khoản tối thiểu quyền, timeout, ngân sách và review bắt buộc.

Codex agent provider đã GA chưa?

Chưa theo thông báo ngày 7/7/2026; GitHub gọi đây là public preview. Tổ chức nên quản lý như tính năng thử nghiệm có nhóm pilot và fallback.

Giới hạn token cao hơn có luôn cho kết quả tốt hơn không?

Không. Context quá lớn có thể tăng độ trễ, chi phí và nhiễu. Nên đặt giới hạn theo tác vụ, đo tỷ lệ hoàn thành và chỉ tăng khi dữ liệu cho thấy thiếu context là nguyên nhân.

MCP server trong workspace có an toàn không?

Chỉ an toàn khi source, version, tool scope và credential được kiểm soát. File cấu hình trong repository giúp minh bạch nhưng không nên chứa bí mật. Mọi thay đổi MCP cần code review.

Debug Logs khác gì telemetry?

Debug Logs phục vụ điều tra sâu một session trong IDE; telemetry phục vụ quan sát tổng hợp qua nhiều session. Kết hợp cả hai nhưng phân quyền và retention khác nhau.

Kết luận

GitHub Copilot cho JetBrains đang tiến gần mô hình “agent control plane” trong IDE: provider có thể thay đổi, model có thể quản lý, token có thể giới hạn, MCP và customizations có bề mặt riêng, permission được chọn theo session, còn debug logs và OpenTelemetry tạo bằng chứng vận hành. Đây là bước tiến đáng giá cho nhóm dùng IntelliJ IDEA, PyCharm hay WebStorm, nhưng chỉ hiệu quả khi đi kèm ranh giới quyền và quy trình review.

Lựa chọn thực dụng nhất không phải bật tất cả. Hãy bắt đầu bằng Default Approvals, worktree, MCP read-only, model catalog nhỏ và telemetry tối thiểu. Sau đó dùng dữ liệu về lỗi, độ trễ, token và test để quyết định phần nào xứng đáng tự động hóa thêm. Khi đó, vibe coding không còn là cảm giác “AI làm được rất nhiều”, mà trở thành một quy trình có thể quan sát, kiểm toán và cải thiện.