Khi Microsoft dùng AI agent "canh gác" docs cho chính mình

Khi Microsoft dùng AI agent "canh gác" docs cho chính mình

Microsoft thừa nhận docs open-source của họ cũng bị lỗi thời — và giải pháp là để AI agent "đi tuần". Đây là bài học (và cách bạn áp dụng ngay) cho team mình.

Một sự thừa nhận hiếm thấy từ ông lớn

Microsoft vừa kể một chuyện mà ít công ty lớn dám nói thẳng: documentation của chính họ — cho các dự án open-source — cũng bị outdated, cũng có bước hướng dẫn không chạy, cũng khiến developer tốn hàng giờ debug thứ đáng ra đã được viết rõ.

Và thay vì thuê thêm người ngồi review docs thủ công, họ giao việc cho AI agents kết hợp với một hệ thống tên là Drasi — một công cụ theo dõi thay đổi dữ liệu và trigger hành động tự động. Mỗi khi code thay đổi mà docs liên quan chưa cập nhật, hệ thống flag ngay. Không đợi ai report, không đợi đến lúc junior mới vào team khóc ròng trên Slack.

Nghe thì đơn giản — nhưng khoan, câu chuyện này dày hơn bạn tưởng.

Phía sau Drasi là cả một cuộc "dọn nhà" lớn

Cùng thời điểm, Microsoft đang làm một việc tham vọng hơn: gom toàn bộ hệ sinh thái AI trên Azure vào một mái nhà chung tên Microsoft Foundry.

Trước đây, muốn dùng AI trên Azure, bạn phải nhảy qua nhảy lại giữa Azure OpenAI Service, Azure Machine Learning, Azure AI Studio... mỗi nơi một cổng, một bộ docs, một cách xác thực khác nhau. Giờ tất cả quy về: Foundry Models (chọn model từ OpenAI, Meta Llama, Mistral...), Foundry Agent Service (build và deploy agent), Foundry Tools (speech, vision, search), và Foundry Control Plane (giám sát toàn bộ).

Hình dung thế này: trước kia bạn học đại học mà mỗi môn một cơ sở khác nhau — sáng chạy Cầu Giấy, chiều sang Thanh Xuân. Foundry là khi trường gom hết về một campus — tiện di chuyển hơn, nhưng cái campus đó cũng cần thời gian để quen đường.

Đây cũng là lý do case study về Drasi thú vị: nó cho thấy Microsoft không chỉ bán platform AI, mà đang tự dùng agent pattern để giải quyết bài toán nội bộ rất thực — giữ cho docs không thối rữa theo thời gian.

Hai kịch bản cho team Việt Nam

Kịch bản 1 — Team 6 người, startup, chưa xài Azure:

Giả sử team bạn có một API backend, docs viết trên Notion hoặc Markdown trong repo. Mỗi sprint release xong, ít nhất 2-3 endpoint đã đổi mà docs vẫn y nguyên. Quen thuộc chưa?

Bạn không cần Foundry hay Drasi. Chỉ cần ghép một workflow đơn giản:

  1. GitHub Actions watch thư mục src/api/ — mỗi khi PR merge vào main có thay đổi ở đây, trigger action
  2. Action chạy một script gọi LLM (qua Ollama local hoặc OpenAI API) so sánh file code đã đổi với file docs tương ứng
  3. Nếu phát hiện sai lệch → tự tạo GitHub Issue gắn tag docs-outdated
# .github/workflows/docs-guardian.yml
on:
  push:
    branches: [main]
    paths: ['src/api/**']
jobs:
  check-docs:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Compare API changes vs docs
        run: python scripts/docs_guardian.py

Toàn bộ setup này làm trong một buổi chiều. Model nhỏ như Mistral 7B qua Ollama là đủ cho tác vụ so sánh text.

Kịch bản 2 — Team 25+ người, enterprise, đang trên Azure với Kubernetes (AKS):

Đây là lúc Foundry thật sự phát huy. Foundry Agent Service cho phép deploy agent mà không cần tự dựng infrastructure — agent scale theo Kubernetes workload, monitor qua Foundry Control Plane. Đặc biệt, Foundry Models cho phép swap model qua cùng một API interface: hôm nay dùng GPT-4o, tuần sau thử Llama — không cần đổi code.

Điểm mình thấy hay nhất: pattern "agent canh docs" không chỉ áp dụng cho documentation. Bạn có thể mở rộng sang canh API contract vs implementation, canh config drift giữa staging và production, hay canh compliance docs vs actual infrastructure.

Cái bẫy mà team nào cũng suýt rơi vào

Mình biết một team từng hào hứng setup hẳn pipeline auto-generate docs từ code bằng LLM. Kết quả? Docs toàn câu kiểu: "Hàm processOrder nhận tham số order và trả về kết quả." Đúng về mặt kỹ thuật, nhưng đọc xong vẫn không biết hàm này dùng khi nào, edge case ra sao.

Bài học rút ra: phát hiện docs sai ≠ viết docs thay người. Drasi + AI agent giỏi ở chỗ "gác cổng" — báo cho bạn biết chỗ nào cần update. Còn viết cho có hồn, có context, có ví dụ... vẫn cần con người. Đừng nhầm hai việc này — nếu không, bạn sẽ có một hệ thống automation hoàn hảo mà output thì không ai thèm mở.

Vậy nên vui hay nên lo?

Foundry là bước đi hợp lý của Microsoft — consolidation giúp developer bớt lạc giữa mê cung services. Nhưng giá trị lớn nhất từ câu chuyện này không nằm ở platform cụ thể nào. Nó nằm ở pattern: dùng agent như một "trưởng lớp" chuyên kiểm tra bài — không làm bài thay ai, nhưng ai chưa nộp thì biết liền.

Pattern này, bạn áp dụng được ngay với Ollama, với GitHub Actions, với bất kỳ LLM nào bạn đang có. Không cần Azure, không cần budget lớn. Như mình đã chia sẻ trong các bài về Ollama trước đây — công cụ chạy local giờ đủ mạnh cho rất nhiều tác vụ kiểu này.

Câu hỏi cuối cùng không phải "Foundry hay không Foundry?" — mà là: team bạn có biết docs mình đang sai ở đâu không? Nếu câu trả lời là "không chắc"... thì bạn biết chiều nay nên làm gì rồi đấy.

---

Bụi Wire — nghiện đọc release notes lúc 2 giờ sáng

Nguồn tham khảo