AI-Native Agent 時代的 AI-Native Engineering
從 Andrew Ng 的 AI Engineering Skills Map，到 2026 年 9 月真正正在成形的 Agent-first Software Development
2026 年 9 月 4 日，Andrew Ng 發表了 AI Engineering Skills Map 系列中關於 Using Coding Agents 的文章，同時期 Claude, Cursor, OpenAI 也發表了許多架構，經驗談，以及商業上的應用，此時將眾家以及自己在正美科技所進行的事情進行彙整，讓大家可以少走些彎路，少踩些坑。
以下這些文章，有點長度，但他對於技術人，對於商業人，對於想要 AI 導入到自己公司的人都會有所幫助，不論你想要自己 vibe coding 或者是你是想要更近一步的 AI 自媒體老師，都應該完整閱讀這篇文章
同時我也希望你可以給我更多回饋，或者加入社團討論
本文開始
如果把整篇文章和 2026 年正在發生的事情放在一起看，以及結合自己在開發 cymkube & cympack 的經驗來說，將整個 ai 智能製造 (ai manufacturing) 的過程來說，回歸到軟體工程，可以歸納成一段話。
軟體工程正在從「Human 寫 Code，AI 幫忙」轉向「Human 定義 Intent、Architecture、Constraints 與 Acceptance Criteria，Agent 負責 Execution，而系統負責 Verification」。
回歸過去就是：
2024
Human writes code
AI assists
↓
2025
Human prompts
Agent edits code
↓
2026
Human specifies intent
Agents execute in parallel
Verifiers inspect output
Humans make judgment
↓
Next
Human manages an engineering system
that continuously produces software
Andrew Ng 認為，Coding Agent 已經不只是「會不會用 Claude Code、Codex 或 Cursor」。
它正在變成一個完整的 Engineering Discipline。而真正重要的技能可以分成五類：
Directing the workflow
Enabling agent autonomy
Reviewing the work
Customizing the agent and its environment
Coding agent foundations
今天最有效的 Coding Agent 工作並不是把一個 Prompt 丟進去，然後讓 Agent 自己跑十個小時。
真正成熟的使用方式，仍然是高度 iterative，依舊類似人類的 PDCA，只是執行者不一定是人類：
Understand
↓
Plan
↓
Execute
↓
Verify
↓
Review
↓
Fix
↓
Deploy
↓
Observe
↓
Learn
↓
再進入下一輪
這個觀點截至 2026 年 9 月，已經可以在 OpenAI、Anthropic、Cursor、OpenCode 等產品的實際架構中看到，而且從中可以看到人類在當中扮演的角色逐漸改變，雖然都是 PDCA 的本質，這還是沒有變。
什麼是重要的？
對 Coding Agent 的定義已經改變：
幫我寫一個 function。
Coding Agent 現在可以執行大量非純 Coding 工作，包括理解大型 codebase、資料分析、操作 terminal、調查 production incident、閱讀 logs、修改 infrastructure、寫測試、review PR、建立文件，甚至協調其他 agents。
因此能力瓶頸開始改變。以前：
想法
↓
工程師理解
↓
工程師設計
↓
工程師寫 Code
↓
工程師 Test
↓
工程師 Deploy
最大的 bottleneck 往往是 Implementation。現在 implementation 的成本快速下降。
於是瓶頸開始往上游與下游移動：
Human
│
What should we build?
│
What should it mean?
│
What constraints matter?
│
How do we know it's right?
↓
Spec
↓
Agent Execution
↓
Verifier
↓
Human Judgment
真正稀缺的東西逐漸不是：
「寫 Code 的手」
而是：
「知道什麼是正確答案的人」。
這也是 Andrew Ng 為什麼一直強調 Engineering Judgment，這部分的觀點，其實和近期 Uncle Bob 觀點完美契合 https://news.anything-ai.xyz/p/zcLPGC-tvgk/
Coding Agent 的標準 Workflow
整個過程概括成三大階段：
| 階段 | 核心問題 |
|---|---|
| Planning | 我們到底要做什麼？ |
| Execution | Agent 應該怎麼完成？ |
| Deployment & Monitoring | 做完後怎麼證明它真的能運作？ |
但 2026 年真正成熟的版本，可以再拆得更細：
1. Intent
↓
2. Research / Explore
↓
3. Specification
↓
4. Architecture
↓
5. Execution Plan
↓
6. Agent Execution
↓
7. Deterministic Verification
↓
8. Behavioral Verification
↓
9. Human Review
↓
10. PR / Merge
↓
11. Deploy
↓
12. Observe
↓
13. Incident / Feedback
↓
14. 更新 Rules / Skills / Spec
最大的不同是：
Code 已經只是中間產物。
Spec、Rules、Tests、Context、Logs、Evals、Artifacts、Permissions 都變成軟體工程的一部分。
Planning：不要一開始就叫 Agent 寫 Code
我們認知到，真正『成熟工程師』首先會控制一件事情：
Agent 什麼時候開始動手？
這很重要。
因為 Agent 最大的問題通常不是「寫不出來」，而是：
很快地寫出錯的東西。
假設你說：
幫我加一個報價功能。
Agent 很可能會馬上：
Create QuoteController
Create Quote model
Create migration
Create routes
Create Blade page
看起來很勤奮。但它根本還不知道所謂的『細節』：
- 報價是否有 revision？
- 一張 RFQ 能不能有多份 Quote？
- Quote 是否需要客戶簽核？
- 幣別？稅？有效期限？
- B2B buyer 跟 internal sales 看到的欄位是否不同？
- PDF 是否必須保存 immutable snapshot？
所以更成熟的方式是：
User Intent
↓
Agent explores repository
↓
Agent asks / infers domain questions
↓
Spec
↓
Architecture
↓
Acceptance Criteria
↓
Implementation
Anthropic 很早就在 Claude Code 的最佳實務裡提出類似的：
Explore → Plan → Code → Commit
並建議複雜問題先探索 codebase、建立 plan，再實作，這也是為什麼在正美科技數位發展部我們深度的與 Claude 進行合作。
Spec 正在重新成為軟體工程核心
AI Coding 最有趣的一個反轉是，以前很多團隊嫌 Spec 太慢。（因為以前 Spec 都需要層層檢驗，層層檢視）
現在 Agent 寫程式太快，
反而沒有 Spec 會更慢。 因為：
Bad spec
×
Fast agent
=
Fast wrong implementation
所以 2026 的成熟團隊開始把自然語言 specification 當成 production asset。一個好的 Spec 不只是：
我要一個登入功能。
而是：
Goal
讓企業客戶可以透過 Email OTP 登入。
Actors
Buyer
Internal Admin
Flow
Buyer 輸入 Email
→ 發送 OTP
→ OTP 10 分鐘有效
→ 驗證
→ 建立 session
Constraints
不得建立密碼
OTP 每個 Email 每分鐘最多請求一次
連續輸入錯誤五次鎖定 15 分鐘
所有 OTP 驗證事件需要 audit log
Acceptance Criteria
未註冊 Email 不洩漏帳號存在與否
Expired OTP rejected
Used OTP cannot be reused
Rate limiting works
Audit log created
這種文件的價值，不只給人類（ Human ）看。它其實變成：
Agent Contract。
2026 年更進一步：Behavior Spec
2026 年 9 月 4 日 Cursor 公布的 Basis 案例非常值得注意。
Basis 做的是高複雜度的會計 Agent。
例如一份 partnership tax return，人工可能需要約 30～40 小時，他們的 Agent 可以花約 6～7 小時完成，但真正困難的不是「最後答案對不對」。
因為高風險工作可能出現：
結果碰巧正確，但是過程錯誤。
例如：Agent 得到正確稅務答案，但引用了錯誤 authority。
所以 Basis 另外建立：
Behavior Spec
也就是定義：
在什麼情境下
Agent 應該：
看什麼 Evidence
↓
做什麼 Decision
↓
採取什麼 Action
↓
留下什麼 Proof
然後 Judge 評估 Agent trajectory，而不是只看最後 output。
這可能會成為接下來非常重要的一種 Agent Engineering 方法。
Execution：Agent Autonomy 不是越大越好
特別提醒：社群媒體很容易把：（特別是 x 或者某些自媒體大神，說的就是那些人）
「Agent 自己跑十幾個小時，就跑出 OOXX」
描述成 AI Engineering 的最高境界。但他認為目前這被過度放大了。真正應該問的是：
這個 Task 最適合多少 Autonomy？
可以用一個簡單模型：
| Task | Autonomy |
|---|---|
| 修改 typo | 極高 |
| 補 unit test | 高 |
| 小 bug fix | 高 |
| 新 API endpoint | 中高 |
| Database migration | 中 |
| Authentication | 中低 |
| Payment | 低 |
| Production data mutation | 非常低 |
| 刪除 production resource | Human gate |
因此真正成熟的 Agent 系統不是：
Full Autonomous = Good
而是：
Autonomy
=
Task Risk
×
Verification Quality
×
Rollback Ability
×
Environment Isolation
如果 Verification 很強，就可以放更多 autonomy。
如果 Verification 很弱，Human 就必須增加 involvement。
這句話可能不是這麼好懂，但你可以留著上面那段公式自己做驗證。
Verification 正在成為最重要的 Engineering Skill
AI 時代很可能發生一個很大的工程角色轉移：
以前
Engineer
=
Implementation
現在
Engineer
=
Intent
+
Architecture
+
Verification
+
Judgment
Agent 說：
Done.
完全沒有意義，真正有意義的是：
Unit tests: PASS
Integration tests: PASS
Static analysis: PASS
Security checks: PASS
Browser test: PASS
Screenshot comparison: PASS
Acceptance criteria: 12/12
No unexpected DB migration
No API contract change
PR ready
也就是：
Don't trust completion.
Trust evidence.
Cursor 的 Cloud Agents 現在會提供 screenshots、videos、logs 等 artifacts，讓使用者不需要只看 Diff，而可以直接看 Agent 怎麼驗證結果。
Codex 也把 terminal logs、tests 等證據當成工作結果的重要部分。
2026 年 9 月真正的 Coding Agent 使用方式
現在大致形成六個層級。
| Level | 工作方式 | Human 工作 |
|---|---|---|
| L0 | AI autocomplete | 寫 code |
| L1 | Chat-based coding | 下 Prompt + 修改 |
| L2 | Interactive Agent | 指揮 Agent |
| L3 | Delegated Agent | 定義 Task + Review |
| L4 | Parallel Agents | 管理多 Agent |
| L5 | Agentic Software Factory | 管理 Intent、Context、Verifier、Policy |
目前很多成熟 AI Engineering 團隊，已經從 L2 往 L3/L4 移動。
目前正美科技數位發展部已經將 Cymkube 這樣的服務整體發展到 L4 ，正在往 L5 方向發展。
OpenAI 在 2026 年公開過一個很極端但值得觀察的內部實驗：一個產品約五個月的建置過程中，由 Codex 產生 application logic、tests、CI、documentation、observability 等程式碼，人類工程師不直接手寫 production code。OpenAI 將核心理念描述為 Humans steer, agents execute，而人的工作轉向建立環境、描述意圖與設計 feedback loops。
這不是代表所有團隊都應該這樣做，而是它展示了一個非常重要的方向：
Harness Engineering。
什麼是 Harness Engineering？
以前：
Model = intelligence
現在比較接近：
MODEL
│
┌────────┴────────┐
│ │
Context Tools
│ │
AGENTS.md MCP
Skills CLI
Memory APIs
│ │
└────────┬────────┘
│
Agent Harness
│
Sandbox / VM
│
Verifier
│
Logs / Artifacts
真正決定 Agent 表現的，不只是 Model。
而是整個：
Model + Harness + Context + Tools + Environment + Verification。
這也是為什麼兩個人使用相同模型，成果可以差非常多。
Context Engineering
2026 年開始，「Prompt Engineering」這個概念本身已經太小。真正需要管理的是：
Context Engineering
也就是：Agent 在每個決策點到底知道什麼？
Context 來源可能包括：
User Intent
Product Spec
Architecture
Repository
AGENTS.md / CLAUDE.md
Rules
Skills
Tool descriptions
API docs
Database schema
Previous decisions
Previous failures
User feedback
Current task state
大家也很清楚，這些東西如果全部塞進 Context，Agent 反而表現會變差。
所以新的 Engineering 問題是：
什麼資訊在什麼時候應該出現？
OpenCode V2 已經把 instructions、AGENTS.md、skills、references、MCP 與 session context 明確當成 context system 的不同來源。
Cursor 也區分：
- Project Rules
- User Rules
- Team Rules
- AGENTS.md
Claude Code 則長期使用：
- CLAUDE.md
- Project settings
- Skills
- Hooks
- MCP
- Subagents
這邊當然還有許多不同陣營，但其實方式都是大同小異。
不要把 AGENTS.md 寫成公司百科全書
一個常見錯誤：
AGENTS.md
公司歷史
產品歷史
100 條 coding rules
Database 全 schema
API 全文件
Deployment 全流程
UI 全 Design System
所有 edge case
最後可能 20,000 tokens。結果：
Agent 每一次 request 都背著一整本員工手冊。
更好的架構是：
AGENTS.md
│
├── 核心 architecture
├── 必須遵守的 rules
├── build/test commands
├── verification requirements
│
└── References
│
├── docs/domain/quote.md
├── docs/security/auth.md
├── docs/api.md
└── skills/
也就是：
Progressive Disclosure
需要時再拿。
Skills 正在取代超大型 Prompt
2026 Coding Agent 一個很明顯的方向是：
把 repeated workflow 變成 Skills。
例如：
/create-api
/fix-issue
/review-security
/create-migration
/check-production-log
/run-e2e
/create-pr
Skill 裡面可以包含：
Instructions
Templates
Scripts
Examples
References
Verification rules
所以 User 不需要每次說：
先查 route
再查 controller
不要破壞 service layer
記得 run phpstan
記得 run tests
記得檢查 API response
最後 create PR
而只要：
Use our backend-feature skill.
Implement QUOTE-183.
OpenAI 目前也把 Skills 定義成把 instructions、resources、scripts 打包的工作單位，並透露內部已經建立數百個 Skills，處理 eval、training runs、documentation、growth analysis 等工作。
Subagents：不是建立一群人格，而是分離 Context
很多人還是會停留在每個 Agent 就是每個角色，每個職能的概念來進行，
通常最常見的例子是這樣的 Multi-Agent （錯誤的例子）：
Architect Agent
Coder Agent
Senior Agent
Junior Agent
Manager Agent
CEO Agent
然後讓它們互相聊天。
然而在我們的經驗以及實際的結果，這通常不是最有價值的 Multi-Agent。
Subagent 真正最大的價值之一是：
Context Isolation
例如：
Main Agent
│
┌──────────┼──────────┐
│ │ │
Explore Security Tests
Agent Agent Agent
│ │ │
findings findings findings
└──────────┼──────────┘
↓
Main Agent
以職能來做區隔，以 workflow 來進行區隔
Explore Agent 可以讀大量舊 code。
Security Agent 可以專心做 security audit。
Test Agent 可以研究 existing test conventions。
Main Agent 不需要把每個檔案與中間推理全部塞進自己的 Context。
OpenCode 目前也正式將 primary agent 與 subagent 分離；subagent 使用自己的 child session 與 fresh context。
Parallel Agent
而上述的概念可以延伸到這邊，當 Task 可以 independent decomposition 就可以 parallel：
Feature
│
├── Agent A: backend
├── Agent B: frontend
├── Agent C: tests
├── Agent D: docs
└── Agent E: security review
往下延伸的方式，比較成熟做法最好是：
SPEC
│
Orchestrator
│
┌─────────┼─────────┐
↓ ↓ ↓
Agent A Agent B Agent C
│ │ │
worktree worktree worktree
│ │ │
└─────────┼─────────┘
↓
Integration
↓
Verify
OpenAI 的 Codex app 已經以 worktrees 支援同 repo 多 agent 隔離工作。
Cursor Cloud Agents 則讓大量 Agents 各自在自己的 VM/environment 裡工作。
到了 2026 年，「Background Agent」已經非常實際
以前 coding agent 基本上跟 IDE 綁在一起。
你必須坐在電腦前：
Prompt
↓
Agent
↓
看
↓
修改 Prompt
現在開始變成：
Slack
LINE
Linear
GitHub
PagerDuty
Schedule
Webhook
│
↓
Cloud Agent
│
isolated VM
│
Build
│
Test
│
Verify
│
Create PR
│
Human Review
Cursor Automations 已經支援 Slack、Linear、GitHub PR、PagerDuty、schedule、webhook 等事件觸發；官方描述的實務包括 issue triage、incident triage、文件更新、security review 與 status reporting。
所以 Coding Agent 慢慢不是：
一個你打開的工具。
而是：
Software Development Infrastructure。
2026 年企業正在怎麼用？
最有意思的是，現在 Agent 已經開始處理過去很難想像交給 Coding AI 的工作。
Nokia 在 2026 年 9 月 2 日公布案例：兩位工程師透過 Cursor 分析超過 5,000 萬行的混合語言 codebase，約兩週完成原先預估需要十多名專家、數個月與客製工具才能完成的 architecture analysis。這是供應商公布的 customer story，因此數字應視為企業自述案例，而不是獨立 benchmark，但它仍反映 Agent 已經從「產 code」進入「理解超大型 codebase 與 architecture decision support」。
Cisco 一位工程主管近期描述自己一天同時管理 10～20 個 Agent，工程工作的挑戰因此從 coding 轉為監督、review、async attention management；這同時也是 Andrew Ng 所說的「Human attention across concurrent agent sessions」開始變成實際管理問題。
OpenAI 內部則觀察到 Agent usage 已經不只工程師：到 2026 年中，Legal、Finance、Recruiting 也大量透過 Codex 執行 automation、data transformation、structured analysis 與 technical execution。
所以 Coding Agent 這個名字，可能很快就會過時。
更準確的說法可能是：
Computer Agent
或者：
Work Agent
完整實戰案例：Laravel B2B 報價功能
現在我們直接做一個完整例子。
假設系統：
Laravel
MySQL
Redis
Queue
REST API
Vue / React frontend
需求：
RFQ 可以由內部業務建立 Quote，客戶可以在線上確認報價。
傳統 Agent Prompt 可能是：
幫我完成 RFQ 報價功能。
不建議。
真正 Agent-native Workflow 應該這樣開始。
Environment 甚至比 Model 更重要
Cloud Agent 經驗時直接指出：
development environment 本身就是產品的一部分。
如果 Agent：
看得到 code，但跑不了 service；可以改 frontend，但開不了 browser；
可以產 migration，但沒有 test DB；可以寫 API，但無法 query integration environment，它就無法真正 close the loop。
所以企業以後可能會有一個新的 infra：
Agent Development Environment
Git
Runtime
Dependencies
Dev DB
Browser
Testing
Internal APIs
Observability
Secrets
Network Policy
Sandbox
Agent 像新員工。
但差別是：
你可能一次 onboard 100 個。
2026 年 Agent 工程最容易踩的坑
這些問題比「Prompt 寫不好」嚴重得多：
| 問題 | 結果 |
|---|---|
| Spec 不完整 | 快速做錯 |
| Context 太多 | Agent attention 被污染 |
| Context 太少 | Agent 猜 architecture |
| 沒有 verifier | Agent 自稱完成 |
| Test coverage 假象 | 錯誤被測試共同合理化 |
| Agent 自己 review 自己 | confirmation bias |
| Parallel agents 改同一區域 | merge chaos |
| 太多 MCP tools | 工具選擇混亂 |
| 權限太大 | blast radius 過大 |
| Production secrets 暴露 | security incident |
| 無 network policy | data exfiltration risk |
| 長時間 unattended | error compounding |
| 每次 Session 從零 | 重複犯錯 |
| 所有 learnings 寫進 Context | context bloat |
| AI code growth 無治理 | agent-generated debt |
安全問題會變得比現在更重要
這是 Agent-first Development 很容易被忽略的部分。
以前：
AI outputs text
現在：
AI
↓
Terminal
↓
Filesystem
↓
Git
↓
Database
↓
Cloud
↓
Production
能力越高，負責的範圍就更大，最近許多案例都有顯示此問題，並不是叫大家不要用 Agent
建議企業 Agent Architecture 應該更接近：
Agent
│
Agent Identity
│
Permission Policy
│
┌─────────┼─────────┐
│ │ │
Git DB Cloud
│ │ │
scoped read sandbox
token only
│
└─────────┬─────────┘
↓
Audit Log
OpenAI 在 2026 年公開其 Codex 內部安全方式時，重點包括 managed configuration、sandbox、network policies、權限邊界以及 agent-native logs。
Anthropic 同樣將問題定義為控制 Agent 的 blast radius，也就是即使失敗，能造成的最大損害是多少。
因此不要把：
--dangerously-skip-permissions
當成 productivity feature。
Anthropic 後來甚至設計 Auto Mode，就是希望在提高 autonomy 的同時，不必直接移除全部 safety boundaries。
MCP 不是越多越好
另一個 2025～2026 常見錯誤是：
GitHub MCP
Slack MCP
Notion MCP
Jira MCP
Database MCP
Sentry MCP
AWS MCP
Browser MCP
CRM MCP
Everything MCP
全部灌進 Agent。
問題是每一個 Tool 都帶來：
Tool description
Parameters
Possible actions
Errors
Context
Permissions
Attack surface
所以成熟架構會變成：
Task
↓
Skill
↓
Need tool?
↓
Load MCP
↓
Execute
↓
Release context
而不是：
所有工具永久存在。
2026 的工程師必須理解 tool call、MCP、context window 之間的互動，而不是把 Agent 當 black box。
人類的工作不會消失，但會往上移
Coding Agent 時代最容易出現兩種錯誤說法：
「工程師都會消失。」
或：
「AI 就只是 autocomplete。」
兩者都太簡單。
我自己認知比較像是，結合各方觀點更可能的是：
之前的狀態
Engineer
├── code
├── debug
├── test
├── refactor
├── docs
└── deploy
AI 後時期變成：
Agent-Native Engineer
├── understand business intent
├── architecture
├── write specifications
├── define constraints
├── design agent environment
├── define verification
├── supervise agent fleet
├── review exceptions
├── manage production risk
└── improve the system
也就是：
Human moves from Execution to Judgment.
專家從執行者變成評判者
最大的 Bottleneck 會變成 Human Attention
假設以前：
一個工程師一天寫：
1 feature
現在他可以啟動：
Agent A
Agent B
Agent C
Agent D
Agent E
Agent F
問題馬上變成：
6 Agents
×
20-minute review
=
120 minutes review
現在大家面臨的問題就變成同時 20 Agents 發出的 PR / Issue 對於人類來說 根本 review 不完。
所以未來真正重要的是：
Attention Allocation
也就是：
哪些 Agent outcome 需要 Human 看？
哪些由 verifier 過掉就好？哪些只有 anomaly 才 escalation？
未來可能是：
100 Agent Tasks
↓
Automated Verification
↓
20 unusual results
↓
AI Review
↓
5 risky cases
↓
Human
Human attention 會變成最貴的 compute。
KPI 不該是 Token 數
Tokenmaxxing 真的是一個很無意義的事情，也該停止這個行為。
真正應該測：
Verified outcomes / Human hour
例如：
Verified PRs
──────────────
Human Review Hour
又會者回到商業價值本身來進行評估產值：
Business Value
───────────────
Human Attention
2026 年目前四種工具大致定位
| 系統 | 目前比較突出的方向 |
|---|---|
| Claude Code | Terminal-first、context、skills、hooks、subagents、MCP |
| Codex | Multi-agent command center、cloud/local、skills、automation |
| Cursor | IDE + cloud agents + automations + artifacts + enterprise orchestration |
| OpenCode | Open harness、agent configuration、primary/subagent、permissions |
但真正長期重要的可能不是選哪一家。
而是：
不要把 Organizational Knowledge 綁死在某一個 Agent 裡。
理想架構：
Company Knowledge
│
├── Specs
├── AGENTS.md
├── Skills
├── Scripts
├── APIs
├── Tests
└── Evals
│
┌───────┼────────┐
↓ ↓ ↓
Claude Codex OpenCode
模型可以換。Harness 可以換。
但以下這些重要的東西，都該留下 應該留下來：
- Domain Context
- Specs
- Verification
- Process
Agent Memory 真正應該記什麼？
不要讓 Agent 記：
Kevin 喜歡 variable name 短一點。
真正有價值的是：
2026-09-03
Quote revision cannot mutate previous quote
because Finance requires historical price snapshots.
Decision:
Revision always creates new quote row.
Reason:
Auditability.
Do not:
UPDATE previous quote.
這叫：
Institutional Memory
也就是讓下一個 Agent 不要重新犯一次錯。
Post-run Retrospective
應該讓 Agent 累積 learnings，例如每次大型 Task 後：
What failed?
Migration assumptions incorrect.
Why?
AGENTS.md did not explain multi-tenant DB.
Fix:
Add tenancy rule to architecture docs.
What repeated work occurred?
Agent repeatedly searched payment lifecycle.
Fix:
Create payment-domain reference.
What verification was missing?
No duplicate webhook test.
Fix:
Add webhook idempotency test template.
然後把結果真正寫回：
Docs
Skills
Tests
Rules
Evals
這樣下一個 Agent 會變強。
不是因為 Model 被 fine-tune，
而是：
Environment learned.
每個事件後真正的學習和回歸校正
未來 12～24 個月，我認為會發生什麼？
接下來就會很直接的往 AI-native 的原生部門開始發展，這並非全部的部門都可以這樣展開，就如同雙軌轉型，小型公司可以很快的進行 AI-native ，但大型公司比較適合採用雙軌轉型的獨立部門機制來進行，
而有特別提醒一下，在摸索一段時間後， 2026 年，真正的架構應該是，
真正的 AI-native 是：
Human
負責
Intent
Judgment
Architecture
Trade-offs
Risk
Trust
↓
Agent System
負責
Search
Analysis
Implementation
Testing
Iteration
Documentation
Monitoring
↓
Deterministic System
負責
Constraints
State
Permissions
Validation
Audit
Verification
因此最後會形成：
Human Judgment
Agent Execution
Deterministic Backbone
這三層，而且每一層都會直接對應到商務流程，商業目標，並非單一任務執行。
結論
過去最好的工程師可能是：
可以很快把複雜需求寫成穩定 Code 的人。
接下來最好的工程師可能是：
能把模糊商業意圖轉換成清楚 Spec、Architecture、Constraints 與 Verification，然後建立一套環境，讓數個甚至數十個 Agents 安全、可靠、持續地完成工作的那個人。
所以未來最有價值的能力不單純是：
Coding
而是：
- Directing
- Context Engineering
- Verification
- Agent Harness Engineering
- Architecture
- Judgment
這些聽起來好像都很技術，但實際上他跟 AI Agent / AI workflow 環環相扣，並且與實際的商業流程是緊密結合在一起，因此如何找到一個適合的 FDE ，或者同時橫向領域跨足技術到商業並且願意親自參與實作的角色，會尤其重要。
這本身展開之後就會是：
一套會自己持續生產、驗證、維護生態系統。
這才是 AI-Native Agent 時代真正開始成形的地方，而這個部分只是剛開始。
留言
張貼留言