1. Research & Planning Agent#

Agent này không viết code. Nó phân tích:

• Cấu trúc codebase — Dự án tổ chức thế nào? Pattern nào đang dùng?
• Dependencies — Packages nào được import? Phiên bản? Breaking changes nào?
• Kiến trúc — Tuân theo quy tắc kiến trúc từ steering file
• Công việc trước — Tham khảo learnings từ task và PR feedback trước

Nó tạo ra task plan (bản kế hoạch có cấu trúc từ quy trình spec-driven Day 2) và chuyển giao.

2. Code Agent#

Agent này thực hiện các thay đổi thực tế. Nó:

• Tạo file mới theo conventions của dự án
• Sửa file hiện tại không làm hỏng code kế cận
• Tạo migration scripts cho thay đổi database
• Cập nhật file cấu hình khi cần

Code agent tôn trọng quy tắc steering file về code style, kiến trúc và bảo mật.

3. Verification Agent#

Agent này chạy sau mỗi thay đổi:

• Chạy test suite của dự án
• Chạy linting và type checking
• Quét lỗ hổng bảo mật (hardcoded secrets, SQL injection)
• Xác thực so với acceptance criteria của spec
• Báo cáo lỗi với file và dòng cụ thể

Nếu verification agent tìm thấy vấn đề, nó loop lại code agent để sửa trước khi tiếp tục.

Giao tiếp Sub-Agent#

Cả ba agent chia sẻ một task spec — tài liệu có cấu trúc giống từ Day 2. Đây là single source of truth mà chúng phối hợp xung quanh. Research agent viết kế hoạch, code agent thực hiện, verification agent kiểm tra — tất cả dựa trên cùng một spec.

Khi code agent gặp sự mơ hồ, nó tham vấn research agent. Khi verification agent tìm thấy lỗi, nó gửi stack trace lại cho code agent. Kiến trúc đa agent này đáng tin cậy hơn một lệnh gọi LLM đơn lẻ vì mỗi agent chuyên biệt và kiểm tra chéo lẫn nhau.

Thiết lập Môi trường#

Agent tự động phát hiện:

1. Dockerfile — Nếu tìm thấy, build full container environment
2. DevFile — Theo spec cho tools, runtimes, và dependencies
3. Cấu trúc dự án — Nếu không có, phân tích package.json, requirements.txt, v.v.

Tính năng auto-detection này rất quan trọng cho tính nhất quán. CI pipeline và autonomous agent của bạn chạy trong môi trường tương đương.

Kiểm soát Mạng#

Cấu hình cho từng task với bốn cấp độ:

Cho ví dụ nâng cấp lodash, “Common dependencies” là đủ — agent cần npm cho phiên bản lodash mới và GitHub để tạo PR.

Quản lý Secrets#

Biến môi trường và secrets được cấu hình cho từng task:

1
{
2
  "env": {
3
    "NPM_TOKEN": "${NPM_TOKEN}",
4
    "GITHUB_TOKEN": "${GITHUB_TOKEN}"
5
  },
6
  "secrets": {
7
    "STRIPE_API_KEY": "${STRIPE_SECRET}"
8
  }
9
}

Secrets được:

• Mã hóa khi lưu trữ
• Không bao giờ lộ trong logs, error messages, hoặc mô tả PR
• Inject dưới dạng biến môi trường trong sandbox
• Giới hạn phạm vi trong một task hoặc session

Gán Nhãn#

Thêm label kiro vào bất kỳ GitHub issue nào:

1
# Từ GitHub UI: thêm label "kiro" vào issue #42
2
# Kiro nhận trong vòng vài phút

Gán Qua Comment#

Dùng /kiro trong comment GitHub issue để giao việc cụ thể:

1
/kiro Implement rate limiting trên /api/login endpoint
2
Dùng pattern rate-limiter middleware có sẵn từ src/middleware/.
3
Thêm tests cho: normal flow, exceeded limit, reset after window.

Kiro lắng nghe tất cả comment tiếp theo trên issue để:

• Làm rõ yêu cầu ban đầu
• Feedback về kết quả trung gian
• Steering adjustments

PR Auto-Fix#

Khi bạn để lại review feedback trên PR mà Kiro tạo:

1
"Hãy dùng format error response tiêu chuẩn: { error: string, code: string }"

Kiro không chỉ sửa PR đó. Nó nhớ preference và áp dụng vào công việc tương lai tự động. Đây là cơ chế học hỏi — feedback của bạn huấn luyện sự hiểu biết của agent về tiêu chuẩn team.

Bước 1: Định nghĩa Task#

Trong autonomous agent chat tại app.kiro.dev/agent:

“Nâng cấp lodash từ 4.17 lên 5.0 trên tất cả microservices trong saaskit-org. Xử lý breaking changes: xóa _.chain, thay đổi signature _.flatten, thay đổi hành vi _.extend. Chạy tests sau mỗi lần nâng cấp. Mở PR riêng cho mỗi service.”

Bước 2: Phân tích#

Agent:

1. Truy vấn GitHub cho tất cả repos trong saaskit-org có chứa lodash trong package.json
2. Tìm thấy 15 service bị ảnh hưởng
3. Phân tích pattern sử dụng lodash của mỗi service
4. Xác định breaking change nào áp dụng cho service nào
5. Tạo task plan sắp xếp theo rủi ro: service ít usage trước, service critical sau

Bước 3: Thực thi#

Cho mỗi service:

1. Clone → tạo branch → cập nhật lodash → sửa breaking changes → cập nhật tests → chạy test suite → tạo PR
2. Nếu tests fail, phân tích lỗi và thử lại với cách tiếp cận khác
3. Nếu thử lại vẫn fail, đánh dấu PR cần human review

Tất cả 15 service được xử lý bất đồng bộ. Mỗi service có sandbox riêng, đội sub-agent riêng, PR riêng.

Bước 4: Kết quả PR#

Mỗi PR bao gồm:

• Tóm tắt thay đổi lodash áp dụng
• Breaking changes đã xử lý và cách xử lý
• Kết quả test (passed/failed với coverage delta)
• Migration notes cho team
• Các quyết định cần human review

Bước 5: Vòng phản hồi#

Bạn review PR #1 và comment:

“Cho việc xóa _.chain — dùng pipe pattern từ fp/ thay vì Promise.all thông thường”

Kiro cập nhật PR #1 và áp dụng cùng pattern cho PRs #2-15 tự động. Team đó không cần lặp lại feedback giống nhau.

So sánh Thời gian#

Phù hợp Hoàn hảo#

• Refactoring xuyên repo — Đổi tên shared library, nâng cấp dependency, thay đổi API contract
• Migration quy mô lớn — Nâng cấp framework (React 18 → 19), database migration, thay đổi cloud provider
• Giảm nợ kỹ thuật — Thay thế API deprecated, xóa code không dùng, chuẩn hóa pattern xuyên repo
• Vá bảo mật — Sửa CVE trên toàn bộ tổ chức trong giờ thay vì tuần
• Tự động hóa onboarding — Thiết lập microservices mới theo patterns có sẵn

Tránh Dùng Khi#

• Sửa một dòng — Nhanh hơn tự làm
• Công việc khám phá — Vibe mode trong IDE tốt hơn cho rapid iteration
• Production cực kỳ nhạy cảm — Dùng per-file approval mode trong IDE
• Task cần tương tác thời gian thực — Agent async theo thiết kế