Agent .NET cần lan can hơn là hào quang

Agent .NET cần lan can hơn là hào quang

Một playbook cho team build agent trong .NET: bắt đầu từ orchestration, guardrail, verifier và audit trail trước khi mơ tới tự động hóa lớn.

“Cho agent tự tạo controller, tự viết test, tự sửa bug luôn được không chị?” — câu này mình nghe từ một tech lead .NET ở Sài Gòn trong một buổi cà phê mà ly đá tan nhanh hơn backlog.

Team của anh, tạm gọi là team Mây, đang có một monolith ASP.NET Core khá già đời: Entity Framework, SQL Server, vài service nội bộ, CI/CD trên GitHub Actions, và một rổ task lặp đi lặp lại như viết unit test, generate API docs, refactor controller cũ. Dev trong team đã dùng coding assistant cá nhân rồi, nhưng giờ lead muốn nâng cấp lên agent chạy theo workflow.

Va chạm nằm ở đây: mọi người nghĩ câu hỏi là “chọn model nào?”. Mình nghĩ câu hỏi đúng hơn là: agent được phép làm gì, kiểm tra bằng gì, và dừng ở đâu?

Nói thẳng ra thì, agent production không phải sạp rau thấy giá mềm là bê cả sọt. Mua nhầm một bó héo còn bỏ được; cho agent đẩy code sai vào pipeline thì cả team ngồi gỡ.

Sơ đồ minh họa cho bài Agent .NET cần lan can hơn là hào quang

Sơ đồ tóm tắt ý chính của bài viết.

Mục tiêu thật: không phải “agent biết code”, mà là “agent không phá nhịp build”

Trong .NET environment, agent có thể giúp nhiều việc rất thực tế:

Nhưng với team Mây, mình không khuyên bắt đầu bằng “agent tự xử ticket từ Jira đến production”. Quá rộng, quá nhiều quyền, quá khó audit.

Mục tiêu buổi đầu nên nhỏ hơn:

Tạo một agent hỗ trợ dev trong pull request, chỉ được đọc repo, sinh patch, chạy test, và ghi lại lý do thay đổi. Không được merge, không được chạm secrets, không được tự sửa test để pass.

Ở đây có vài thuật ngữ cần neo nhanh:

Độc giả nên đổi cách nghĩ ở điểm này: model chỉ là người trả giá; orchestration mới là cái cân. Cân điêu thì hàng nào cũng lệch.

Checklist cho team Mây trước khi cắm agent vào repo

Nếu bạn đang lead một team .NET, đây là checklist mình sẽ bắt làm trước khi viết dòng code agent đầu tiên.

1. Chọn một workflow có verifier rõ

Ưu tiên việc có pass/fail cụ thể:

Tránh workflow kiểu “cải thiện architecture”, “làm code sạch hơn”, “tối ưu performance” nếu chưa có metric. Agent rất giỏi làm bạn thấy bận rộn, nhưng không đồng nghĩa tạo giá trị.

2. Tách quyền đọc, quyền sửa, quyền chạy

Đừng cấp một token toàn năng. Với repo enterprise, nên có policy kiểu:

3. Ghi state qua file hoặc storage nhỏ

State là bộ nhớ tiến trình: agent đã thử gì, fail ở đâu, bước tiếp theo là gì. Với coding agent, một file như .agent/session.md đã đủ cho vòng đầu.

Ví dụ:

# Agent Session
Goal: Add unit tests for OrderPricingService
Attempt 1: Generated tests for discount rules
Result: dotnet test failed - missing mock for IClock
Next: Add fixed test clock
Files touched: tests/OrderPricingServiceTests.cs

Không có state, mỗi lần agent chạy lại giống người đi chợ quên mình vừa kỳ kèo sạp nào: mất thời gian, lặp lỗi, và dễ làm bừa.

4. Có stop condition

Stop condition là điều kiện dừng: pass test, hết số lần thử, hoặc cần human approval. Ví dụ:

Agent không có điểm dừng là vòng lặp đốt token có kỷ luật rất kém.

Playbook 30 phút: dựng agent phụ tá PR cho .NET

Ví dụ cụ thể: team bạn có service BillingService và muốn agent sinh unit test cho một class mới sửa. Đây là bản playbook tối giản, không phụ thuộc vendor cụ thể.

Bước 1: Đóng khung nhiệm vụ

Tạo file agent-task.md:

Goal: Add unit tests for BillingService.CalculateInvoiceTotal
Scope:
- Read src/Billing/** and tests/Billing/**
- Modify only tests/Billing/**
Verifier:
- dotnet test tests/Billing.Tests/Billing.Tests.csproj
Stop:
- Max 3 attempts
- Stop if production code needs changes
Output:
- Patch summary
- Test result
- Risks or assumptions

Điểm quan trọng: agent không được tự diễn giải “muốn sửa production code cũng được”. Nếu cần sửa production code, nó phải báo lại.

Bước 2: Cho agent chạy trong sandbox

Dù bạn dùng local runner, CI job riêng, hay platform agent, nguyên tắc vẫn là chạy trong môi trường cách ly.

Pseudo-flow:

# checkout branch
 git checkout feature/billing-rule

# restore and baseline
 dotnet restore
 dotnet test tests/Billing.Tests/Billing.Tests.csproj

# agent receives task + repo context
# agent edits only allowed files

# verify
 dotnet test tests/Billing.Tests/Billing.Tests.csproj
 git diff --stat
 git diff

Ở mức production, bạn nên log:

Đây là audit trail. Khi PR có bug, team không cần đoán “AI đã làm gì?”, mà có biên bản để soi.

Bước 3: Thêm verifier, đừng thêm niềm tin

Verifier nên nằm ngoài ý chí của agent. Ví dụ:

name: agent-pr-check
on: [pull_request]

jobs:
  verify:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-dotnet@v4
        with:
          dotnet-version: '8.0.x'
      - run: dotnet restore
      - run: dotnet build --no-restore
      - run: dotnet test --no-build

Nếu agent viết test rồi sửa luôn logic test để dễ pass, verifier vẫn có thể pass giả. Vì vậy cần guardrail thêm: trong task generate test, cấm sửa production code; trong task fix bug, bắt buộc có test mới chứng minh bug.

Bước 4: Tách planner và worker nếu chi phí bắt đầu đau

Với workflow phức tạp, không nhất thiết model mạnh nhất làm mọi thứ. Một pattern đáng dùng là:

Cách này hợp với team đã có nhiều task lặp. Đừng triển khai ngay nếu team mới thử agent; nhưng khi token bill bắt đầu làm kế toán nhìn bạn như nhìn hóa đơn điện tháng nóng, hãy quay lại pattern này.

Ba bẫy làm agent enterprise trông thông minh nhưng chạy dở

Bẫy 1: Agent được phép sửa cả đề thi

Trong loop engineering, vòng lặp chỉ đáng tin khi có verifier không bị agent thao túng. Nếu agent vừa sửa code vừa sửa test evaluation tùy ý, bạn không còn đang tối ưu chất lượng; bạn đang cho nó dọn đường để tự thắng.

Áp dụng vào .NET: nếu task là cải thiện BillingService, agent không được tự sửa assertions trong test cũ trừ khi có human approval.

Bẫy 2: Không phân biệt assistant và automation

Assistant gợi ý cho dev. Automation tự chạy theo điều kiện. Hai thứ này cần governance khác nhau.

Một agent chỉ comment PR có thể được nới quyền đọc. Một agent tự push commit phải bị giới hạn scope, bắt buộc verifier, và cần audit trail. Đừng dùng cùng một policy cho cả hai.

Bẫy 3: Quá mê autonomy, quên approval point

Approval point là điểm cần người duyệt trước khi đi tiếp. Trong enterprise .NET, mình sẽ đặt approval khi:

Agent càng gần dữ liệu nhạy cảm, approval càng phải rõ. Tự động hóa không có nghĩa là bỏ người khỏi vòng đời phần mềm; nó nghĩa là đưa người vào đúng đoạn cần phán đoán.

Framework 4 ô: chọn mức agent theo độ rủi ro

Nếu là mình, mình sẽ chia adoption thành 4 mức, thay vì hỏi chung chung “có nên dùng agent không?”.

| Mức | Agent làm gì | Quyền | Verifier | Khi nào dùng |
|---|---|---|---|---|
| 1. Commenter | Review PR, tóm tắt diff, gợi ý test | Read-only | Human review | Bắt đầu an toàn |
| 2. Patch maker | Sinh patch cho test/docs/refactor nhỏ | Sửa file giới hạn | Build/test/lint | Team đã có CI ổn |
| 3. Loop runner | Tự thử-sửa-chạy test trong N vòng | Sandbox + allowlist tool | Test + stop condition | Task đo được rõ |
| 4. Delegated workflow | Planner giao việc cho worker agent | Policy theo role | Audit + approval | Team có platform maturity |

Team Mây cuối cùng chọn mức 2 trước: agent sinh unit test và docs trong PR, dev review diff, CI quyết định pass/fail. Sau vài tuần mới tính tới loop runner cho một số package ít rủi ro.

Quyết định đó nghe không hào nhoáng, nhưng đáng tiền. Vì production không thưởng cho demo biết múa; production thưởng cho hệ thống biết dừng đúng lúc.

Việc nên làm ngay trong một buổi

Nếu bạn đang muốn đưa agent vào .NET repo, đừng bắt đầu bằng procurement dài lê thê. Làm một spike nhỏ:

  1. Chọn một project test có dotnet test chạy ổn.
  2. Viết agent-task.md với scope, verifier, stop condition.
  3. Chạy agent chỉ được sửa tests/**.
  4. Bắt nó xuất patch summary, commands run, remaining risks.
  5. Review diff như review junior dev: không cảm tính, không nể vì “AI viết”.

Sau buổi đó, team sẽ biết ba thứ rất thật: task nào hợp agent, guardrail nào còn thiếu, và CI hiện tại có đủ làm verifier không.

Kết lại gọn: agent trong .NET chỉ đáng tin khi bạn thiết kế cái lồng chạy việc trước khi chọn con chim hót hay. Ra chợ thì cứ kỳ kèo giá, nhưng vào production nhớ kiểm cân.

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

Nguồn tham khảo