Fi1osof · Nikolai Lanets
kỹ sư nghiên cứu · nhật ký công khai
bộ đếm thời gian không chạy
🇷🇺Русский🇬🇧English🇻🇳Tiếng Việt

Nhiệm vụ: Chế độ Tác nhân Điều tra Sự cố Dự án

Chế độ Tác nhân Điều tra Sự cố Dự án

25.08.2026fi1osof.ru

Thiết kế và triển khai một quy trình làm việc an toàn, trong đó AI tự động thu thập ngữ cảnh dự án, kiểm tra các giả thuyết và ghi lại kết quả điều tra dựa trên một mục tiêu duy nhất.

Mục tiêu

Đưa việc cộng tác với AI lên một tầm cao mới: người dùng xác định mục tiêu làm việc bằng ngôn ngữ tự nhiên, ví dụ:

«Tìm hiểu lý do tại sao dự án X không hoạt động»

Sau đó, tác nhân sẽ tự động thực hiện quá trình từ tìm kiếm dự án và thu thập ngữ cảnh đến kiểm tra giả thuyết và ghi lại kết quả vào fi1osof.ru.

Kịch bản Mục tiêu

Ví dụ về quy trình làm việc mong muốn:

  1. Tìm dự án theo tên hoặc ID.
  2. Lấy ngữ cảnh hiện tại của dự án đó.
  3. Đọc các công việc liên quan.
  4. Đọc các worklog gần đây.
  5. Xem các sự kiện/thay đổi gần đây của dự án.
  6. Kiểm tra tính khả dụng của trang web/API/dịch vụ, nếu có.
  7. Lấy dữ liệu về các lần triển khai, lỗi, nhật ký (log) và trạng thái môi trường gần nhất.
  8. Đưa ra một số giả thuyết về nguyên nhân gây ra sự cố.
  9. Kiểm tra những giả thuyết có thể kiểm chứng bằng các công cụ có sẵn.
  10. Tạo công việc mới hoặc cập nhật công việc hiện có.
  11. Ghi lại kết quả điều tra, bằng chứng, liên kết và các bước tiếp theo vào công việc.

Tóm lược:

tìm dự án
→ thu thập các thay đổi gần đây
→ xem các công việc đang mở
→ đọc các worklog gần đây
→ kiểm tra tính khả dụng của trang web/API
→ xem các lỗi và bản triển khai
→ đưa ra giả thuyết
→ kiểm tra các giả thuyết khả thi
→ tạo/cập nhật công việc
→ ghi lại kết quả điều tra

Những gì đã có sẵn

GraphQL API đã cung cấp các thực thể cơ bản cần thiết để bắt đầu quá trình này:

  • dự án (projects);
  • công việc (tasks);
  • nhật ký công việc (task worklogs);
  • kỹ năng (skills);
  • bộ hẹn giờ/hoạt động (timers/activity);
  • executeSkill;
  • readWebPage;
  • các truy vấn/thao tác GraphQL khác.

Điều này đã cho phép triển khai một phần chu trình tác nhân mà không cần hệ thống điều phối bên ngoài riêng biệt.

Những gì còn thiếu

1. Ngữ cảnh Kỹ thuật Dự án Được Chuẩn hóa

Cần có khả năng truy xuất rõ ràng các nguồn kỹ thuật liên quan đến dự án:

  • kho mã nguồn (repositories);
  • các dịch vụ (services);
  • môi trường production/staging/dev;
  • URL công khai và nội bộ;
  • điểm cuối API (API endpoints);
  • các lần triển khai (deployments);
  • quá trình chạy CI/CD;
  • nhật ký (logs);
  • lỗi (errors);
  • giám sát (monitoring);
  • cấu hình (configuration);
  • tài liệu (documentation).

Nếu không có điều này, tác nhân có thể phân tích tốt các nhiệm vụ và lịch sử làm việc, nhưng không phải lúc nào cũng có thể xác định được nguyên nhân gốc rễ kỹ thuật của sự cố.

2. Mối quan hệ Rõ ràng Giữa các Thực thể

Nên có một đồ thị quan hệ có thể đọc bằng máy, ví dụ:

Project
├─ Repository
├─ Service
│  ├─ Environment
│  ├─ Endpoint
│  ├─ Deployment
│  └─ LogSource
├─ Task
│  └─ TaskWorkLog
└─ Documentation

Điều quan trọng là tác nhân không xác định quyền sở hữu đối tượng chỉ dựa trên các tên gọi giống nhau.

3. Dòng Hoạt động / Lịch sử Thay đổi (Activity feed)

Cần có một cách thống nhất để trả lời câu hỏi:

«Điều gì đã thay đổi ngay trước khi sự cố xảy ra?»

Các sự kiện hữu ích:

  • thay đổi nhiệm vụ;
  • worklog mới;
  • bản triển khai (deployment);
  • commit/release;
  • thay đổi cấu hình;
  • health-check thất bại;
  • lỗi mới;
  • thay đổi DNS/SSL;
  • khởi động lại dịch vụ;
  • các hành động của người dùng/tác nhân ảnh hưởng đến dự án.

Nên có một truy vấn duy nhất cho các sự kiện gần đây của dự án với bộ lọc theo thời gian và loại sự kiện.

4. Công cụ Kiểm tra Giả thuyết An toàn

Tác nhân cần các hành động chẩn đoán chỉ đọc (read-only) hoặc được kiểm soát, chẳng hạn như:

  • HTTP health-check;
  • đọc trang web;
  • kiểm tra API endpoint;
  • lấy HTTP status/headers/body fragment;
  • tra cứu DNS (DNS lookup);
  • kiểm tra chứng chỉ SSL;
  • đọc nhật ký (logs);
  • kiểm tra trạng thái dịch vụ;
  • đọc các bản triển khai gần nhất;
  • chạy kiểm tra (test);
  • thực thi kỹ năng chẩn đoán.

Một phần trong số này có thể được xây dựng dựa trên readWebPage và executeSkill hiện có.

5. Chính sách Tự chủ

Cần xác định rõ ràng những hành động nào tác nhân có thể tự thực hiện.

Được phép thực hiện mà không cần xác nhận thêm

  • đọc dữ liệu;
  • tìm kiếm dự án và các thực thể liên quan;
  • thực hiện chẩn đoán chỉ đọc;
  • đưa ra giả thuyết;
  • đọc nhật ký và hệ thống giám sát;
  • tạo worklog chẩn đoán;
  • tạo công việc thông thường nếu đó là kết quả tự nhiên của cuộc điều tra;
  • bổ sung kết quả chẩn đoán vào công việc.

Chỉ thực hiện khi có lệnh rõ ràng từ người dùng

  • triển khai lên production (production deploy);
  • khởi động lại các dịch vụ production;
  • thay đổi cấu hình production;
  • xóa dữ liệu;
  • thay đổi hàng loạt;
  • giao dịch tài chính;
  • các hành động quản trị;
  • thay đổi quyền truy cập;
  • bất kỳ hoạt động nào khác có khả năng gây phá huỷ.

Kỹ năng Cấp cao (High-level Skills)

Không chỉ cần các kỹ năng cấp thấp như «lấy danh sách công việc», mà còn cần các quy trình ở cấp độ mục tiêu làm việc.

Các kỹ năng có thể có:

  • investigate_project
  • check_project_health
  • analyze_recent_failures
  • summarize_project_state
  • investigate_incident
  • analyze_recent_changes

Ví dụ, investigate_project có thể xác định một quy trình có thể lặp lại:

resolve project
→ collect context
→ collect recent activity
→ inspect tasks/worklogs
→ run health checks
→ inspect deployments/errors/logs
→ produce hypotheses
→ test hypotheses
→ persist findings

Kỹ năng nên mô tả một thuật toán điều tra, các quy tắc an toàn và định dạng ghi nhận kết quả thay vì chỉ một câu trả lời cụ thể.

Định dạng Kết quả Điều tra

Nên lưu kết quả vào Task.content hoặc worklog bằng định dạng Markdown.

Ví dụ về cấu trúc:

# Kết quả điều tra

## Triệu chứng
...

## Những gì đã kiểm tra
- ...
- ...

## Quan sát
- ...

## Giả thuyết
1. ...
2. ...

## Nguyên nhân đã xác nhận
...

## Bằng chứng
- [log / URL / deployment / commit](...)

## Những việc đã làm
- ...

## Hành động tiếp theo
- [ ] ...
- [ ] ...

Nguyên tắc Lưu trữ Công việc Quan trọng

Đối với các công việc trong fi1osof.ru, cần tuân thủ việc phân tách:

  • description — mô tả ngắn gọn về bản chất của công việc, nghĩa đen là vài câu;
  • content — toàn bộ nội dung chính, chi tiết, Markdown, liên kết, danh sách kiểm tra (checklist), ví dụ, ngữ cảnh kỹ thuật và kết quả phân tích.

Không sử dụng description làm trường nội dung dài chính của công việc.

Giai đoạn Thực tế Đầu tiên

Trước khi triển khai toàn bộ quy trình làm việc, cần kiểm toán (audit) lược đồ GraphQL hiện tại và các kỹ năng có sẵn:

  1. Xác định nguồn dữ liệu nào trong số các nguồn được liệt kê đã tồn tại.
  2. Kiểm tra các mối quan hệ hiện có giữa Project, Task, TaskWorkLog, các kỹ năng và các thực thể khác.
  3. Tìm các thao tác có sẵn để chẩn đoán web/API.
  4. Xác định xem các mô hình deployments, logs, environments, repositories, events/activity đã có sẵn chưa.
  5. Thực hiện phân tích khoảng trống (gap analysis): những gì có thể làm ngay bây giờ / những gì còn thiếu trong API / những gì còn thiếu trong các kỹ năng.
  6. Dựa vào đó, thiết kế quy trình investigate_project tối thiểu.

Tiêu chí Hoàn thành

Một nhiệm vụ được coi là đã hoàn thành khi một lệnh dạng:

«Tìm hiểu tại sao haih.net hôm nay không hoạt động»

có thể được xử lý bởi tác nhân như một mục tiêu làm việc, thay vì một loạt lệnh GraphQL thủ công, và kết quả là tác nhân:

  • tự động thu thập ngữ cảnh có liên quan;
  • cho biết chính xác những gì nó đã kiểm tra;
  • phân biệt rõ ràng giữa sự thật và giả thuyết;
  • kiểm tra các giả thuyết khả thi;
  • không thực hiện các hành động nguy hiểm mà không có sự cho phép;
  • lưu tóm tắt kết quả điều tra vào fi1osof.ru.