Archive
Archive
Browse English articles by publication year.
2026
Record of Quantitative Trading System Development (6): Architecture Evolution and Reconstruction Decisions
Review the five refactorings of Micang Trader, explaining how the system evolved from the initial snapshot to a clearer target architecture, and incorporated technical debt and ADR decisions into long-term governance.
Quantitative trading system development record (4): test-driven agile development (AI Agent assistance)
Starting from a cross-night trading day boundary bug, we reconstruct the test defense line of the quantitative trading system: defect-oriented testing pyramid, AI TDD division of labor, boundary time, data lineage and CI Gate.
Quantitative trading system development record (5): Python performance tuning practice
Transform performance optimization from empirical guesswork into a verifiable investigation process: start from the 3-second chart delay, locate the real bottleneck, compare optimization solutions, and establish benchmarks and rollback strategies.
Quantitative trading system development record (7): AI engineering implementation - from speckit to BMAD
Taking the trading calendar and daily aggregation requirements as a single case, explain how AI engineering can enter the delivery of real quantitative systems through specification drive, BMAD role handover and manual quality gate control.
Record of Quantitative Trading System Development (Part 3): Python Pitfalls Practical Pitfalls Avoidance Guide (Part 2)
Continuing to reorganize Python risks into a reference piece: how GUI lifecycles, asynchronous network failures, security boundaries, and deployment infrastructure affect the long-term stability of quantitative trading systems.
Quantitative trading system development record (2): Python Pitfalls practical pitfall avoidance guide (1)
Reorganize Python traps from a long list into an engineering risk reference for quantitative trading systems: how to amplify the three types of risks, syntax and scope, type and state, concurrency and state, into real trading system problems.
Quantitative trading system development record (1): five key decisions in project startup and architecture design
Taking Micang Trader as an example, this article starts from system boundaries, data flow, trading-session ownership, unified backtesting/live-trading interfaces, and AI collaboration boundaries to establish the architecture thread for the quantitative trading system series.
From enterprise-level CF platform to cloud native (1): Architect's review - the gains and losses of microservice governance in the era of enterprise-level CF platform
Based on the front-line architecture practice of enterprise-level CF platforms from 2015 to 2020 and industry observations from 2015 to 2026 (to date), we review the microservice governance design decisions in the Cloud Foundry era and analyze which ones have withstood the test of time and which ones have been reconstructed by the cloud native wave.
From enterprise-level CF platform to cloud native (2): Observability-driven governance—from monitoring large screens to precise decision-making systems
With 6 years of practical experience as an enterprise-level platform architect, we analyze the core position of observability in microservice governance, from data islands to OpenTelemetry unified standards, and build a governance system for accurate decision-making.
From enterprise-level CF platform to cloud native (3): The evolution of traffic management - from Spring Cloud Gateway to Gateway API and Ambient Mesh
Review the practice of Spring Cloud Gateway in the enterprise-level CF platform, analyze the standardization value of Kubernetes Gateway API, explore the evolution logic from Service Mesh to Ambient Mesh, and provide a decision-making framework for enterprise traffic management selection.
From enterprise-level CF platform to cloud native (4): Redefining elastic fault tolerance—from Hystrix to adaptive governance
Review Hystrix's historical position in microservice elastic governance, analyze Resilience4j's lightweight design philosophy, explore new paradigms of adaptive fault tolerance and chaos engineering, and provide practical guidance for enterprises to build resilient systems.
From enterprise-level CF platform to cloud native (5): The evolution of release governance—from manual approval to progressive delivery
Review the manual approval model of traditional release governance, analyze the evolution of blue-green deployment and canary release, explore the new paradigm of GitOps and progressive delivery, and provide practical guidance for enterprises to build an efficient and secure release system.
From enterprise-level CF platform to cloud native (6): Summary—an architect’s perspective on enterprise-level microservice governance
Review the evolution of microservice governance over the past ten years from 2015 to 2026 (to date), refine the first principles of architects, summarize the implementation paths and common pitfalls of enterprise-level governance, look forward to future trends, and provide a systematic thinking framework for technical decision-makers.
Spring AI and LangChain4j: Enterprise Java AI Applications and AI Agent Architecture
A production-grade guide to Spring AI, LangChain4j, RAG, tool calling, memory, governance, observability, reliability, security, and enterprise AI operating boundaries.
Original Analysis: Why FastAPI Rises in the AI Era—The Engineering Value of Type Hints and Async I/O
Analyzing Python type hints, async I/O, and FastAPI's rise logic; establishing a feature-capability matching framework for LLM API service development
Original Analysis: Why Python Monopolizes LLM Development—Ecosystem Flywheel and Data Evidence
Synthesizing multi-source data from Stack Overflow 2025, PEP 703 industry testimonies, and LangChain ecosystem to analyze the causes and flywheel effects of Python's dominance in AI
Original Analysis: Capability Building for Python Developers in the AI Tools Era—A Practical Guide for Frontline Engineers
Based on Stack Overflow 2025 data, establishing a capability building roadmap from beginner to expert, providing stage assessment, priority ranking, and minimum executable solutions
Python Memory Model Deep Dive Series Overview (7 Parts)
This page serves as the navigation hub for the Python Memory Model Deep Dive Series, providing complete entry points in reading order to establish a comprehensive cognitive framework from underlying mechanisms to engineering practice to career development.
Java Memory Model Deep Dive: From Happens-Before to Safe Publication
A production-grade deep dive into JMM, happens-before, volatile, final fields, optimistic locking, memory barriers, cache coherence, lock semantics, HotSpot implementation, and concurrency diagnostics.
Modern Java Garbage Collection: Production Judgment, Evidence Collection, and Tuning Paths
Use symptoms, GC logs, JFR, container memory, and rollback discipline to choose and tune G1, ZGC, Shenandoah, Parallel GC, and Serial GC without cargo-cult flags.
Concurrency Governance with Virtual Threads in Production Systems
Understand throughput, blocking, resource pools, downstream protection, pinning, structured concurrency, observability, and migration boundaries for Project Loom.
Valhalla and Panama: Java's Future Memory and Foreign-Interface Model
Separate delivered FFM API capabilities from evolving Valhalla value-type work, and reason about object layout, data locality, native interop, safety boundaries, and migration governance.
Java Cloud-Native Production Guide: Runtime Images, Kubernetes, Native Image, Serverless, Supply Chain, and Rollback
A production-oriented Java cloud-native guide covering runtime selection, container resources, Kubernetes contracts, Native Image boundaries, Serverless, supply chain evidence, diagnostics, governance, and rollback.
JIT and AOT: From Symptoms to Diagnosis to Optimization Decisions
A production decision guide for HotSpot, Graal, Native Image, PGO, and JVM diagnostics.
Java Ecosystem Outlook: JDK 25 LTS, JDK 26 GA, and JDK 27 EA
An enterprise architecture view of Java's next decade: version strategy, roadmap status, ecosystem boundaries, cloud-native operations, AI governance, and performance evolution.
Original Interpretation: The Three-Layer World of Python Memory Architecture
Why doesn't memory drop after deleting large lists? Understanding the engineering trade-offs and design logic of Python's Arena-Pool-Block three-layer memory architecture
Original Interpretation: Python Garbage Collection - The Three Most Common Misconceptions
Deconstructing the three major misconceptions about reference counting, gc.collect(), and del statements, establishing a complete cognitive framework for Python GC mechanisms (reference counting + generational GC + cycle detection)
Original Analysis: 72 Processes vs 1 Process—How GIL Becomes a Bottleneck for AI Training and PEP 703's Breakthrough
Reviewing real production challenges at Meta AI and DeepMind, analyzing PEP 703's Biased Reference Counting (BRC) technology, and exploring the implications of Python 3.13+ nogil builds for large-scale model concurrency
Original Analysis: Python as a Glue Language—How Bindings Connect Performance and Ease of Use
A comparative analysis of ctypes, CFFI, PyBind11, Cython, and PyO3/Rust, exploring the technical nature and engineering choices of Python as a glue language for large models
Why do you need to be a coding mentor for AI?
When AI programming assistants become standard equipment, the real competitiveness is no longer whether they can use AI, but whether they can judge, calibrate and constrain the engineering output of AI. This article starts from trust gaps, feedback protocols, evaluation standards and closed-loop capabilities to establish the core framework of "Humans as Coding Mentors".
Panorama of AI programming ability evaluation: from HumanEval to SWE-bench, the evolution and selection of benchmarks
Public benchmarks are not a decoration for model rankings, but a measurement tool for understanding the boundaries of AI programming capabilities. This article starts from benchmarks such as HumanEval, APPS, CodeContests, SWE-bench, LiveCodeBench and Aider, and explains how to read the rankings, how to choose benchmarks, and how to convert public evaluations into the team's own Coding Mentor evaluation system.
How to design high-quality programming questions: from question surface to evaluation contract
High-quality programming questions are not longer prompts, but assessment contracts that can stably expose the boundaries of abilities. This article starts from Bloom level, difficulty calibration, task contract, test design and question bank management to explain how to build a reproducible question system for AI Coding Mentor.
Four-step approach to AI capability assessment: from one test to continuous system evaluation
Serving as a coding mentor for AI is not about doing a model evaluation, but establishing an evaluation operation system that can continuously expose the boundaries of capabilities, record failure evidence, drive special improvements, and support collaborative decision-making.
Best Practices for Collaborating with AI: Task Agreement, Dialogue Control and Feedback Closed Loop
The core skill of being a Coding Mentor for AI is not to write longer prompt words, but to design task protocols, control the rhythm of conversations, identify error patterns, and precipitate the collaboration process into verifiable and reusable feedback signals.
Practical cases: feedback protocol, evaluation closed loop, code review and programming education data
Case studies should not stop at “how to use AI tools better”. This article uses four engineering scenarios: model selection evaluation, feedback protocol design, code review signal precipitation, and programming education data closed loop to explain how humans can transform the AI collaboration process into evaluable, trainable, and reusable mentor signals.
From delivery to training: How to turn AI programming collaboration into a Coding Mentor data closed loop
The real organizational value of AI programming assistants is not just to increase delivery speed, but to precipitate trainable, evaluable, and reusable mentor signals in every requirement disassembly, code generation, review and revision, test verification, and online review. This article reconstructs the closed-loop framework of AI training, AI-assisted product engineering delivery, high-quality SFT data precipitation, and model evaluation.
From engineering practice to training data: a systematic method for automatically generating SFT data in AI engineering
Following the data closed loop in Part 7, this article focuses on how to process the screened engineering assets into high-quality SFT samples and connect them to a manageable, evaluable, and iterable training pipeline.
Future Outlook: Evolutionary Trends and Long-term Thinking of AI Programming Assessment
As the final article in the series, this article reconstructs the future route of AI Coding Mentor from the perspective of engineering decision-making: how evaluation objects evolve, how organizational capabilities are layered, and how governance boundaries are advanced.
The minimum upgrade path from blog to technology platform (1): from 'file pile' to 'thematic'
When you have more than 20 blog posts, readers start to get lost in time. This article shares a practical experience: why thematicization is the first step in blog upgrade, and how to judge whether you have reached the moment where you need to upgrade.
Agent Runtime does not have to be local, Colab MCP gives a more realistic direction
The value of Colab MCP is not only to run Python on the cloud, but also to turn the agent's execution environment into a notebook space that is visible, editable, and can continue to work. For many tasks, what really matters is not the remote execution itself, but how the remote artifact supports human-machine collaboration. This article is based on Google's introduction to Colab MCP Server and extends my complete understanding of runtime surface, artifact-centered design, remote workbench and visibility trust mechanism.
A truly mature Eval Harness will not just focus on the answer
If an eval harness can only tell you the success or failure of a task, but cannot explain whether the agent called the correct capabilities, in what environment it was executed, why it failed, and why it succeeded, then what it gives is not a systematic judgment, but just a score card. This article is based on LangChain's discussion of skills eval and extends my complete understanding of artifact-based scoring, invocation metrics, trace design, workflow eval and evaluation histology.
The most misleading thing about Agent Benchmark is not the model score, but the infrastructure noise.
In agentic coding eval, the model is not the only variable. Resource headroom, kill semantics, concurrency pressure, network status, and sandbox behavior can all change task results. If these conditions are not transparent, small margins on the leaderboard are often less telling than they seem. This article is based on Anthropic's analysis of infrastructure noise and extends my complete understanding of agent benchmark interpretability, disclosure discipline, repeated experiments, and system-level evaluation perspectives.
What the long-term task agent really lacks is not intelligence, but the handover, recovery and acceptance capabilities.
The failure of long-term task agents often does not stem from the model's inability to think, but from the system's failure to design 'handover, recovery, verification, and continuation' as first-class citizens. This article is based on Anthropic's discussion of long-running agent harness, extending my complete views on cross-session execution, state externalization, feature contract, smoke test, browser verification and multi-round execution structure. It also explains why a truly usable agent does not run for a long time at a time, but can catch it round after round.
What MCP changes is not tool access, but the cost structure of Agents.
The real significance of MCP is not just to unify tool access, but to move a large number of intermediate processes that should be handled by the runtime out of the expensive LLM cycle. What it changes is not 'how many tools can be connected', but how the agent uses context, code execution and runtime control flow. This article is based on Anthropic's discussion of code execution with MCP and extends my complete understanding of direct tool-calling, progressive disclosure, runtime economics and executable skills.
Agent Harness is not a supporting role, but the most underrated main battleground of AI engineering in 2026
What really determines the upper limit of an agent is often not the model itself, but the harness organized around the model. This article is based on LangChain's disassembly of the agent harness, extending my complete understanding of file systems, code execution, context management, verification closed loops and long-term task endurance. It also explains why the focus of AI engineering competition in 2026 is shifting from 'model capabilities' to 'working system design'.
Overview of in-depth interpretation of OpenClaw (10 articles)
This page is the navigation page of the OpenClaw in-depth interpretation series, providing full access in reading order.
Original interpretation: Why do OpenClaw security incidents always happen after 'the risk is already known'?
Why do OpenClaw security incidents always happen after 'the risk is already known'? This article does not blame the model for being out of control, but instead asks about the design flaws of execution rights: when the system puts execution rights, audit rights, and rollback rights on the same link, how does organizational blindness amplify controllable deviations into accidents step by step?
Original interpretation: Why is the lightweight Agent solution likely to be closer to production reality than the 'big and comprehensive' solution?
This is not a chicken soup article praising 'lightweight', but an article against engineering illusion: many OpenClaw Agent stacks that appear to be stronger only front-load complexity into demonstration capabilities, but rearrange the cost into production failures and early morning duty costs.
Original interpretation: Treat Notion as the control plane of 18 Agents. The first thing to solve is never 'automation'
This article does not discuss whether the console interface is good-looking or not, but discusses a more fundamental production issue: when you connect 18 OpenClaw Agents to the Notion control plane, is the system amplifying team productivity, or is it amplifying scheduling noise and status chaos?
Original interpretation: Putting Agent into ESP32, the easiest thing to avoid is not the performance pit, but the boundary illusion.
This article does not describe the ESP32 Edge Agent as a cool technology trial, but dismantles the four most common misunderstandings: running the board does not mean the system is usable, being offline is not just a network problem, and local success does not mean on-site maintainability. Edge deployments require new engineering assumptions.
Original interpretation: When OpenClaw costs get out of control, the first thing to break is never the unit price, but the judgment framework.
If OpenClaw API fee control only focuses on the unit price of the model, it will usually turn into an illusion of cheapness in the end: the book will look good in the short term, but structural waste will still quietly accumulate in the background. This paper reconstructs a cost framework including budget boundaries, task layering and entry routing.
Original interpretation: When the Agent tries to 'take away the password', what is exposed is never just a leak point
Rewrite 'Agent knows your password' into a more uncomfortable accident review: the real failure is not a certain encryption action, but the team's use of credentials as a default capability that is always online, constantly visible, and constantly callable. This article discusses runtime governance gaps.
Original interpretation: Why what OpenClaw really lacks is not more prompt words, but a tool firewall that dares to say 'no'
Many teams pin OpenClaw safety on prompt constraints, but what really determines the upper limit of accidents is not what the model thinks, but whether the system allows the model's ideas to be directly turned into tool execution. This article proposes a four-layer governance framework of 'intention-adjudication-execution-audit'.
Original interpretation: It is not difficult to deploy OpenClaw to AWS. The difficulty is not to mistake 'repeatable deployment' for 'already safe'
Dispel a very common but dangerous illusion: when teams say 'we've reinforced it with Terraform', they often just complete the starting point, but mistakenly believe that they are at the end. IaC can make deployment consistent, but it cannot automatically make OpenClaw systems continuously secure.
Original interpretation: The real priority for Agent credential security is not 'where to put it', but 'who can touch it and when'
Refuting an all-too-common misconception: OpenClaw credential security is complete as long as key escrow, encrypted storage, and rotation are done. The reality is just the opposite. The most likely place for trouble often occurs at runtime - not 'where' it is placed, but 'who can touch it and when'.
Original interpretation: Looking at the three types of OpenClaw security articles together, it is not the vulnerabilities that are really revealed, but the lag in governance.
When the three topics of prompt word injection, credential leakage, and tool firewalls are put on the same table, you will find that they point to the same core contradiction: OpenClaw's capabilities are expanding faster than execution rights management. This article synthesizes the common conclusions of three security articles.
The smallest upgrade path from blog to technology platform (2): The design art of labels and topics
What is the difference between topics and tags? Why is it harder to find content when there are too many tags? This article dismantles the three most common misunderstandings in content taxonomy and shares a practical 'three-tier tag system' design method.
The smallest upgrade path from blog to technology platform (3): Build a platform-based homepage - let readers go from 'seeing' to 'discovering'
Thematicization solves the problem of content attribution, but what should readers see when they open the homepage? This article shares how to design a 'content discovery' homepage, rather than a simple time flow list.
The smallest upgrade path from blog to technology platform (4): Astro + Content Collections practical guide
Convert the design concepts from the first three articles into code. This article is a complete technical implementation guide, including all codes such as project structure, Schema design, dynamic routing, search integration, etc.
Original interpretation: Engineering practice of data preparation - from raw data to AI-ready training set
In-depth exploration of the engineering methodology of LLM data preparation, from IBM Data Prep Kit tool analysis to enterprise-level data pipeline construction, revealing the systematic engineering practices behind high-quality training data
Original interpretation: The art of LLM fine-tuning—from data preparation to model refinement
In-depth exploration of the complete practical path of fine-tuning large language models, from engineering thinking in data preparation to detailed control of model training, reveals the key methodologies that turn general AI into domain experts.
Original interpretation: Agent quality assessment - the cornerstone of trust in the AI era
In-depth analysis of the essential challenges of Agent quality assessment and why quality engineering is the key to determining the success or failure of AI products
Original interpretation: MCP protocol - the USB-C moment of the Agent ecosystem
An in-depth analysis of the essence of the Model Context Protocol protocol design and why standardization is the key to the prosperity of the Agent ecosystem
Original Interpretation: Contextual Engineering—The Forgotten Core Battlefield in the AI Era
An in-depth analysis of the essential challenges of Agent memory systems and why context management is the key to determining the success or failure of AI products.
Original interpretation: Kaggle white paper "Introduction to Agents" - AI Agent introduction and architecture panorama
In-depth analysis of the five levels, core architecture and production practices of Agent, and sorting out the key framework and inspiration of the Kaggle white paper "Introduction to Agents"
Original interpretation: From prototype to production - the engineering transition of the Agent system
In-depth analysis of the core challenges of Agent production and how to transform Agent prototypes into reliable production-level systems
Technical Interpretation Index | Curated Translations
Original technical interpretation and selected articles from foreign technology communities to explore best practices in AI engineering
Original interpretation: In-depth analysis of AI Agent system failure modes
Failure mode analysis based on practical experience of multi-Agent systems, combined with predictive thinking from science fiction literature
Original interpretation: The essential challenge of observability in Agent production environment
An in-depth analysis of the fundamental differences between Agent and traditional software, and why traditional monitoring methods fail in the AI era
Original interpretation: How AI Agent implements large-scale testing quality access control
Practical analysis of AI testing agent based on Node.js project scaffolding, and explore the implementation ideas of automated quality access control
Original interpretation: How Coding Agent reconstructs the collaboration paradigm of the EPD team
Explore the profound impact of AI coding agents on engineering, product, and design roles, as well as fundamental changes in the way teams are organized
Original interpretation: Discovery and prevention of silent hallucination in RAG system
Based on an in-depth analysis of RAG system failure cases in the production environment, we explore the nature of the silent illusion problem, monitoring blind spots, and architectural-level solutions.